dmetzger

Nimm Daim's Worte für bare Münze und den besten Rat, den Du bekommen kannst. Wahrscheinlich fällt Dir eine Migration ein, um Altlasten loszuwerden. Besser ist, AD in Ordnung zu bringen und dann zu aktualisieren. Du kannst dann auch die bestehende Exchange-Organisation beibehalten, und das ist ebenfalls die beste Wahl, wenn Du keine oder wenig Erfahrung mit der Migration von Exchange-Organisationen hast. Du brauchst Dich nicht um die ACLs auf Dateiservern etc. zu kümmern, nicht um Dinge wie SID-Historie usw. Es lohnt wahrscheinlich in diesem Fall den Aufwand nicht, so lange die Domäne die gleiche bleiben soll.

Mit welcher Begründung?

Das Forum hat eine ausgezeichnete Suchfunktion. http://www.mcseboard.de/ms-exchange-forum-80/exchange-2010-zertifkat-offizieller-ca-abgelehnt-wegen-domainname-171508.html#post1055072

Die Kennwortrichtlinien sind DIE Ausnahme. Zwar kann man die Aussage von iDiddi in Technet so finden: Domain Level Account Policies "The Account policy must be defined in the Default Domain Policy or in a new policy that is linked to the root of the domain and given precedence over the Default Domain Policy, which is enforced by the domain controllers in the domain." Dann gibt es aber auch diesen Technet-Artikel: Updating the Default Domain Policy GPO and the Default Domain Controllers Policy GPO "Changes in settings to domain security policy should always be made to the Default Domain Policy GPO." Wir folgen Variante 2 seit Windows 2000, und diese wird von den lehrenden Directory Services-Spezialisten in Redmond explit auch empfohlen, mit der Begründung, dass nie eine Gruppenrichtlinie Vorrang vor der Standard-Domänenrichtlinie haben soll - deshalb heisst sie ja so. Und ich dopple nach: Modifying Account Policies in the Default Domain GPO: Group Policy "If you want to modify the account policies at the domain level, it is recommended that you modify the default domain GPO." Zu Deutsch: Kennwortrichtlinien gehören in die Standard-Domänenrichtlinie.

In der Standard-Domänenrichtlinie "Maximales Kennwortalter" aktivieren und auf 0 Tage setzen (läuft nie ab). In jeder Richtlinieneinstellung steht eine Erklärung dazu. Das hilft.

Ein fröhliches "Weiter gehts!" in die Morgenrunde. Nein, aber er ist soooo müde.

Hast Du bereits versucht, den WSUS zu deinstallieren und anschliessend unter Verwendung von Port 8530/8531 erneut zu installieren?

Ich für meinen Teil werde ihn mal vorläufig weiter SBS 2011 nennen: Announcing Windows Small Business Server 2011 - The Official SBS Blog - Site Home - TechNet Blogs

Windows Server 2008 R2: High Availability Database Availability Group Design Examples: Exchange 2010 SP1 Help

Korrekt. NLB und Failover Clustering kann nicht gleichzeitig auf einem Windows-Server aktiviert sein. Eine andere Variante ist die Verwendung eines vorgeschalteten NLB-Gerätes. In diesem Fall kann man die Standardrollen CAS, MB und HT auf zwei Geräten installieren und Ausfallsicherheit für alle 3 Rollen erreichen.

Mir missfällt der Gedanke, externe Benutzer zu Domänenbenutzern zu machen. AD LDS lässt sich mit AD DS synchronisieren: Synchronize with Active Directory Domain Services Für W2K8R2 müsstest Du zuerst das AD-Schema mit dem ADSchemaAnalyzer exportieren und in AD LDS importieren. AD LDS auf W2K8R2 liferet nur die Schemas für W2K3 und W2K8 mit.

Hier gibts Informationen zu RODC im Perimeter: Deploying RODCs in the Perimeter Network Download details: Active Directory Domain Services in the Perimeter Network (Windows Server 2008) Ich weiss nicht, ob ich ein solches Szenario mit einem RODC lösen möchte (müsste die ganze Umgebung sowie die Anwendungen kennen). Mir fallen im ersten Moment eher Begriffe wie Radius (interne Benutzer) und AD LDS auf Standalone (externe Kunden) ein.

Selbstverständlich. Intern Zone firma.ch anlegen, falls sie noch nicht existiert, und Hosteintrag "mail" erstellen. Ggf. externe Hosts wie "www" mit externer IP nicht vergessen. Damit die Outlook 2007/2010-Clients beim internen Zugriff nicht einen Zertifikatsfehler reklamieren, gemäss folgendem KB vorgehen: Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: "The name of the security certificate is invalid or does not match the name of Das hier ist evt. ebenfalls von Interesse: The EXPTA {blog}: How to fix MSExchangeTransport Event ID 12014 on Edge and Hub Transport servers Aus Deiner Beschreibung meine ich zu lesen, dass der externe Zugriff direkt auf den CAS erfolgt. Ein TMG 2010 davor wäre die sicherere Variante.

Sind das interne oder externe Nutzer respektive Mitarbeiter oder Gäste?

Guten Morgen allesamt! *Lichteinschalt* Warum denn? Mir kann sie nicht lange genug sein. Es gibt ja soviel zu tun :D Bin seit 5 im Büro, E-Mail und Dokumentation schreiben. Muss zudem eine Präsentation für die Microsoft Certified Career Conference vorbereiten und dafür eine Demoumgebung bauen. Später gehts zum Kunden, am Nachmittag warten die Berufsschüler. Nur das Wetter macht nicht mit, es ist plötzlich sehr kalt und trüb geworden. Der Hund hat sich im warmen Korb unter seinen Pfoten versteckt.

Im SBS 2008 ist Exchange Server 2007 bereits enthalten. Im angekündigten SBS 2011 wird Exchange Server 2010 enthalten sein.

Je mehr physisches RAM eingebaut ist, desto manueller sollte man die Auslagerungsdatei festlegen. Die Auslagerungsdatei kommt zum Zug, wenn sich das physische RAM erschöpft. Je mehr physisches RAM, dsto weniger Bedarf besteht für eine grosse Auslagerungsdatei. Wir haben Hyper-V-Server mit bis zu 384 GB RAM. Nach alter Manier bedeutet das eine Auslagerungsdatei von 576 GB. Da braucht man schon fast ein SAN für die Auslagerungsdatei :p Auch wenn die Auslagerungsdatei auf einem Server mit viel physischem RAM nie so geschrieben wird, kann es im Betrieb ohne manuelle Verwaltung zu Problemen kommen. So reklamiert etwa SharePoint 2010, dass zu wenig Speicherplatz auf dem laufwerk mit der Auslagerungsdatei zur Verfügung stehe, auch wenn noch 100 GB frei sind. SharePoint rechnet einfach Kapazität minus maximale Grösse Auslagerungsdatei und erschrickt... Heisst also: Wenn viel physisches RAM, dann Auslagerungsdatei manuell verwalten und in der Grösse deutlich einschränken. Je nachdem genügen 4 oder 8 GB maximale Grösse.

Dann ist gut. Habe bereits befürchtet, es handle sich um ein Kundensystem,. und wir sollen Dir unentgeltlich bei jedem Schritt genauste Anleitung geben, statt nur die eine oder andere hilfreiche Information beizusteuern.

@Cordial: Ist die Nachricht von jetzt verschiedenen Helfern noch immer nicht angekommen? Hyper-V muss für die Gäste (VMs, child partitions, wie auch immer) die Hardware emulieren können und benötigt daher direkten Zugriff auf die Hardware. Informiere Dich bitte über die Grundlagen, statt immer wieder das selbe zu fragen. Danke. Windows Server 2008 R2: Virtualization with Hyper-V: FAQ

Warum Exmerge? Es handelt sich um Postfachverschiebungen. Ist das Dein eigenes System oder das eines Kunden?

Einige Bemerkungen: - Von Exchange 2000 auf Exchange 2010 muss eine zweifache Migration erfolgen und gleichzeitig ein Architekturwechsel von 32 Bit auf 64 Bit; - Exchange 2010 auf einem DC ist nicht empfohlen aber möglich (z.B. Small Business Server 2011); - Von AD 2000 auf AD 2008R2 muss ein Architekturwechsel 32 Bit auf 64 Bit erfolgen. Es ist in jedem Fall kein In-Place-Upgrade möglich. Der Weg von W2K/E2K zu W2K8R2/E2K10 (jeweils gleiches Servergerät, 1 altes und 1 neues Servergerät verfügbar) erfolgt wie nachstehend, um AD-Versionskonflikte mit Exchange Server auszuschliessen (mit jeweils mehreren Schema-Aktualisierungen für AD und Exchange Server, DNS-Anpassungen etc.). Die Schritte aus der Vogelperspektive sind: 1. Zweites Servergerät als DC mit W2K3 x64 in die Domäne aufnehmen; 2. E2K7 auf dem neuen zweiten DC installieren; 3. Postfächer und öffentliche Ordner migrieren; 4. E2K entfernen; 5. alten DC mit W2K herabstufen und aus der Domäne nehmen; 6. alten Server mit W2K8R2 installieren und zum DC in bestehender Domäne heraufstufen; 7. E2K10 auf altem Server installieren; 8. Postfächer und öffentliche Ordner migrieren; 9. E2K7 deinstallieren; 10. DC mit W2K3 herabstufen und aus der Domäne nehmen; 11. neuen Server mit W2K8R2 installieren und zum DC in bestehender Domäne heraufstufen; 12. E2K10 auf neuem Server installieren; 13. Postfächer und öffentliche Ordner migrieren; 14. E2K10 von altem Server deinstallieren; 15. alten DC mit W2K8R2 herabstufen und aus der Domäne nehmen. Übrig bleibt 1 neues Servergerät/DC mit W2K8R2 und E2K10. Etwas Lektüre dazu: Upgrading to Exchange 2007: Exchange 2007 Help You Had Me At EHLO... : Exchange Server and Windows Server 2008 Der zweite Link erklärt, weshalb ich die Kombination W2K3/E2K7 für den Zwischenschritt beschreibe an Stelle von W2K8/E2K7.

Zum Nutzen anderer Forumsteilnehmer - was waren Fehler und Lösung?

Es kommt vor, dass Vertrauensstellungen aus irgendwelchen Gründen nicht mehr funktionieren und neu eingerichtet werden müssen. Erleben wir in grösseren Infrastrukturen manchmal. Ein weiteres Beispiel fällt mir ein, nämlich die Umwandlung einer transitiven Gesamtstruktur-Vertrauensstellung in eine nicht-transitive externe Vertrauensstellung bei einem Kunden, der seine aus einer zuvor einzelnen Domäne bestehende Gesamtstruktur um zwei Subdumänen erweitert hat und diese explizit von der Vertrauensstellung ausnehmen will. (Hoffe, das ist einigermassen verständlich formuliert.)

Im Prinzip nichts, wenn die gleiche Vertrauensstellung mit den gleichen Einstellungen wiederhergestellt wird. Selbstverständlich ist kein Zugriff auf Resourcen in einer anderen Gesamtstruktur möglich, wenn temporär keine Vertrauensstellung existiert. Anschliessend geht es jedoch normal weiter, d.h. Gruppen aus der vertrauten Gesamtstruktur können wieder aufgelöst und für Zugriffe in der vertrauenden Gesamtstruktur autorisiert werden. Gute Literatur gibt es hier: How Domain and Forest Trusts Work: Domain and Forest Trusts Ein Punkt bei der Einrichtung von Vertrauensstellungen ist die Erreichbarkeit von PDCs (Kennwörter Vertrauensstellungen).

Na, na bitte! Ein bisschen mehr Respekt, ist ein Exchange Server. So, hier hat keiner das Nachtlicht eingeschaltet. Also lasse ich das Licht weiter brennen und wünsche allen einen schönen Sonntag.