Christoph35

Na dann ist s ja wunderbar, wenn die Namensauflösung denn jetzt auch intern und extern funktioniert :) Christoph

Die MCP ID steht schon auf dem Ausdruck, den Du vom TestCenter bekommen haben solltest. (oben rechts unter dem MS-Logo) Bis zum Erhalt der Mail von MS dauert das in der Regel so 2-3 Werktage. Christoph

Wenn Boise dann den Thread auch mal wirklich liest :rolleyes: Christoph

Hi, dann lies am besten mal in der Technical Library zum Thema DNS nach. Das ist für AD und Exchange nämlich recht wichtig ;) http://technet2.microsoft.com/windowsserver/en/technologies/featured/dns/default.mspx und http://technet2.microsoft.com/WindowsServer/en/Library/7f6df44c-06c3-4b92-ba32-63d895a7924b1033.mspx Kurz gesagt: forwarding (weiterleitung) wird über die Eigenschaften des DNS Servers eingerichtet. Root Hints (Hinweise auf das Stammverzeichnis): hier findet man die DNS Server, die als erste vom DNS Server befragt werden, wenn ein DNS Server nicht selbst auflösen kann und keine Weiterleitung konfiguriert hat. Christoph

Vielleicht hilft euch das hier weiter: http://www.microsoft.com/downloads/details.aspx?FamilyID=d9f3a35e-1046-47b5-b09b-bda9de60cd9d&DisplayLang=en Weiter unten gibts auf der Seite gibts auch Whitepapers zum Thema. Christoph

Ich nehme mal an, der Exchange FE ist kein DC. Wenn dem so ist, musst Du im DNS auf dem EXFE in der DMZ eine sekundäre Zone für Firma.de erstellen, mit dem DNS im internen Netz als Master. Auf dem internen DNS musst du Zonentransfers zum EXFE erlauben und am besten auch eine Benachrichtigung für den EXFE konfigurieren. Wenn der DNS im internen Netz selbst keine Internet-Auflösung über die Root Servers machen soll, musst Du auf ihm eine Weiterleitung zum EXFE einrichten. Auf dem EXFE kannst du ggf. noch ein Forwarding zum DNS eures ISP einrichten, aber eigentlich sollte er über die Root Hints das auch so können. Dann kann der ExFE interne Namen auflösen, was er braucht um mit dem DC und dem EXBE zu kommunizieren und er kann Internet-Namensauflösung machen. Christoph

Hi, wenn Du nach diesem Artikel vorgehst, sollte es funktionieren, jedenfalls aus dem internen Netz. Ich habe das schon getestet. http://www.petri.co.il/configure_rpc_over_https_on_a_single_server.htm Von aussen ist es natürlich eine andere, ganz schön komplexe, Geschichte. Da könnte ich dir sagen, wie das mit einem ISA 2004 geht. Christoph

Demnach kann der DNS im internen Netz keine Internet-Namensauflösung machen? Tja, wenn das nicht gewünscht ist, dann installiere DNS in der DMZ und arbeite mit conditional forwarding. D.h., Namen für dein internes Netz müssen über den DC/DNS im internen Netz aufgelöst werden, Internet-Namen leitest du an einen DNS weiter, der das kann. Dann lässt du den Exchange auf diesen DNS Server zeigen. Wenn es kein Problem damit gibt, dass ein interner DNS Internetnamen auflöst, solltest du Grizzly´s Ansatz umsetzen. Natürlich müssen die Firewall Regeln entsprechend angepasst werden. Christoph

Falls ihr W2K3 R2 habt: da sind sie dabei. Richtig Sinn macht Sharepoint aber eigentlich nur in Verbindung mit Office 2003. Da ist die Integration am besten gelungen. Christoph

Hi, ich habe sie in Englisch gemacht und hatte damit keine Probleme. Allerdings habe ich mich auch mit einem englischen Exchange auf beide Tests vorbereitet gehabt und kann englisch ziemlich gut. Vorteil ist, du bekommst insgesamt 30 Minuten Zeitbonus, obwohl du sie vielleicht nicht brauchen wirst. Die Prüfung ist nicht schwer und ich habe mich dazu mehrfach hier geäußert, einfach mal die Boardsuche anwerfen ;) Christoph

Hi, also, bei Double Take läuft das so, dass die Datenbanken und Logs in Echtzeit auf den anderen Server gespiegelt werden. Weiter muss eine Überwachung auf dem Zielserver eingerichtet werden, der checkt, ob der SourceServer online ist (Heartbeat). Fällt der SourceServer jetzt aus, übernimmt der Targetserver IP und Name des SourceServers (zusätzlich zur eigenen IP und dem eigenen Namen) und fährt dann die Exchange-Dienste hoch. Geht der SourceServer wieder online, müssen zunächst die Daten auf dem Source wieder mit dem auf dem Target synchronisiert werden, außerdem werden beim Failback die Exchangedienste auf dem Target beendet und auf dem Source gestartet und IP und Namen des Sourceservers auf dem Targetserver "fallengelassen". Im Prinzip also ähnlich wie beim Cluster, nur dass man die Daten auf 2 Servern hat und diese dementsprechend synchronisiert werden müssen. Christoph

Hi, ja, die WSS können auch schon Versionierung und Check-in/Check-out machen. Christoph

CSVDE oder LDIFDE helfen dir hier weiter. Hilfe dazu gibts unter Windows in den Hilfedateien oder hier im Board. :) Christoph

Glückwunsch zu den bestandenen Tests :jau: Die 294 fand ich auch einiges schwieriger als die 293. Christoph

Es gibt noch andere Software, die sowas bereitstellen kann. Schau mal bei NSI-Software nach DoubleTake. Wir nutzen das für File- und Exchange-Dienste. Ganz billig ist es aber nicht (im unteren - mittleren vierstelligen Euro-Bereich). Es gibt aber auch noch andere ähnliche Produkte, bei denen ich aber nicht weiß, wie es da mit Exchange aussieht. Christoph

Off-Topic: Hehe, mag sein, aber ich wette, dafür machst Du mir in anderen Dingen noch was vor ;) Allerdings, RPC/HTTP musste man doch schon für die 284 drauf haben Kann mich nicht mehr so genau erinnern, ist schon 8 Monate her :D Christoph

Bist Du dir sicher, die reverse-lookup-Zone richtig angelegt zu haben? Rechtsklick auf Reverse-Lookup-Zones, Neu, dann im Assistent auf der 3. Seite nach dem WelcomeScreen die richtige Netzwerk ID eingeben. Dann noch auswählen, ob dynamische Updates zugelassen werden oder nicht. Nach dem du die Zone angelegt hast, am besten gleich am DNS Server ein IPconfig /registerdns bzw. den Eintrag für den DNS Server ggf. manuell anlegen. Christoph

Über OWA Wenn du gesagt hättest "Exchange FrontEnd Server", der auch für OWA genutzt wird, könnte ich dir zustimmen :) Wenn Du Exchange RPCoverHTTPS nutzen willst, muss der RPCProxy Dienst installiert werden und die Clients verbinden sich dann mit dem virt. Verzeichnis "RPC". Damit wird eine HTTPS Verbindung aufgebaut, in der die RPC Verbindung getunnelt wird. Mit OWA (das im virt. Verzeichnis /exchange/ und /exchweb liegt) hat das nicht so viel zu tun ;) Christoph

Naja, in dem Thread steht, dass dieses Computerset auftauchen kann, wenn der Server Domainmember wird, bevor man ISA installiert. Ich habe erst W2K3 installiert, dann der Domain hinzugefügt, dann ISA installiert. Trotzdem keine Spur von einem DC ComputerSet. Ich stimme Grizzly zu, das sollte der MS Support klären. Christoph

Also, ich habe hier ISA 2004 SE und EE SP2, es gibt definitiv keine vordefinierte Gruppe "Domain Controllers". Was es gibt ist "Anywhere", "IPSec Remote Gateways" und "Remote Management Computers". Christoph

Guten Morgen zusammen, bin eben aus der ISA 2004 Prüfung raus und habe mit 929 Punkten :shock: :D bestanden. 50 Fragen sind in 150 Minuten zu beantworten (ohne die Zeit für das Abnicken der Statements). Schwerpunkt ist eindeutig VPN (Remote Access und Site-to-Site). Ansonsten sollte man sich gut mit der Konfig. von ISA Clients auskennen. Alles in allem war die Prüfung für mich nicht ganz so schwer, wie ich befürchtet hatte. Sims gibts noch keine. Gruß Christoph

Wozu sollte das gut sein? Das braucht nur der Exchange um sich damit gegenüber dem Client zu authentifizieren. Ich habe es bei meinen Tests so gemacht, dass ich das RootCA Zertifikat der einen Domain einem Client einer Workgroup oder anderen Domain zur Verfügung gestellt habe, und es dort in den Speicher der vertrauenswürdigen Stammzert.-Stellen importiert habe. Wenn dann der Name des Ex.-Serverzerts. mit dem der Site übereinstimmt, gibt es keine Meldung über nicht vertrauenswürdige Zertifikate und der Browser kann ohne weiteres OWA aufrufen. /edit: und Outlook kann dann auch RPC/HTTPS machen. Christoph

Hi, wenn ich dich richtig verstanden habe, wolltest du auch das Zert. des Exchange Servers auf dem Client installieren und das ist nicht nötig. Installierst Du das Zert. der CA, die dem Ex. dessen Webserver Zert. ausgestellt hat, funktioniert es. Aber das sage ich eigentlich schon die ganze Zeit :suspect: Christoph

Das Stammzertifikat ist aber nicht das des Ex.-Servers, sondern das der das Zertifikat ausstellenden CA... Wenn dieses Zertifikat (der ausstellenden CA) als gültig anerkannt wird, ist damit auch das Zertifikat, das der Ex.-Server präsentiert, als gültig anerkannt. Die Antwort auf deine Frage lautet also: schau in das Zertifikat, gehe auf den Zertifikats Pfad und installiere alle Zertifikate, die dem des Ex. übergeordnet sind, in die entsprechenden Zertifikatsspeicher (hier: die des Users) auf dem Client. (also trusted root CAs und ggf. intermediate CAs). Das ist genau das, was in dem von Dir selbst mehrfach zitierten Artikel steht. Ich habe das mehrfach in VM-Umgebungen getestet und es funktioniert. Christoph

In beiden Artikeln steht nichts davon, dass das Zertifikat des Exchange Servers auf dem Client installiert werden muss, wenn doch, bitte hier den Wortlaut posten... Was da steht, und was ich bereits erwähnt habe in Post #5, ist, dass der Client in der Lage sein muss, dass Zertifikat der CA zu überprüfen, die das Zertifikat des Exchange Servers ausgestellt hat. In der Praxis wird es meistens so sein, dass der RPCoverHTTP/OWA-Anbieter ein Zertifikat einer öffentlichen Zert.-Stelle erwirbt und dieses für den Webserver verwendet, oder derjenige, der dem Zert. vertrauen soll, muss eben das Root-Zertifikat auf seinem Rechner den vertrauenswürdigen Stammzertifizierungsstellen hinzufügen. Hier noch mal ein Zitat aus dem 2. von dir verlinkten Artikel: Gruß Christoph