12
Exchange 2013: Outlook Anbindung von nicht Domänenmitglieder
Hallo zusammen,
ich suche derzeit die optimale Lösung für die Anbindung von Outlook (2010) Clients an einen Exchange 2013. Die Clients sind NICHT Mitglied der Domäne.
Es handelt sich um ein kleines Büro mit Win Home Clients. Außerdem wird AD und Exchange auf einer Hardware ohne Virtualisierung betrieben
(Ich weiß, dass MS das nicht unbedingt empfiehlt und kann mit den Einschränkungen leben; bei vielen hier im Forum läuft das wohl ohne Probleme - man muss nur aufpassen welche Dienste man auf dem Server installiert).
Ich habe vor mit dem selbstsignierten Exchange Zertifikat zu arbeiten (schon deswg. weil ich auf dem Server keine Zertifizierungsstelle installieren will) - für ein kleines Büro ist dies aus meiner Sicht auch ausreichend.
Nun suche ich die optimale Konfiguration für die Anbindung der Clients.
Erfolgreich und ohne großen Stress konnte ich bisher leider nur die Anbindung über RPC over HTTP testen. Sprich bei der Einrichtung des Cients auf "weitere Einstellungen" und die Proxyeinstellungen konfigurieren:
Das Ganze scheint auf den ersten Blick auch zu funktionieren. Allerdings bekomme ich bei der Anzeige des Verbindungsstatus immer einen Fehler:
Ich bin mir nicht sicher, ob ich dadurch irgendwelche Einschränkungen habe - dieser 1 Fehler der immer angezeigt wird macht mir auf jeden Fall "angst". Wenn ich Outlook über Domänenmitglieder einrichte habe ich hier immer 0 bei Fehler stehen. Der Fehler ist nicht immer in der gleichen Zeile - manchmal ist er auch bei "Verzeichnis" vorhanden.
Zudem denke ich wäre eine verschlüsselte Verbindung (auch wenns nur im lokalen Netzwerk mehr oder weniger in dem kleinen Büro egal ist) wahrscheinlich besser.
Eine SSL Verbindung bekomme ich bei RPC over HTTPs aber nicht ohne Probleme hin - zumindest habe ich es nicht geschafft.
Noch besser wäre natürlch wenn alles wie bei Domänenmitgliedern (ohne RPC?) laufen würde - ich glaube aber, dass man das wg. des Zertifikats nicht hinbekommt, oder? (Hab viel ausprobiert aber bin leider nicht zu einem aktzeptablen Ergebnis gekommen).
Was ist aus Eurer Sicht die Beste Methode um nicht Domänenclients in meinem Fall an den Exchange anzubinden?
Für wertvolle Tipps und ggf. sogar einer guten Anleitung wäre ich sehr dankbar (im web kursieren sehr viele "Anleitungen" - u.a. mit Anpassung der hosts usw. bin mir aber nicht sicher was wirklich zuverlässig funktioniert und gut ist)
Viele Grüße,
Malungo
ich suche derzeit die optimale Lösung für die Anbindung von Outlook (2010) Clients an einen Exchange 2013. Die Clients sind NICHT Mitglied der Domäne.
Es handelt sich um ein kleines Büro mit Win Home Clients. Außerdem wird AD und Exchange auf einer Hardware ohne Virtualisierung betrieben
(Ich weiß, dass MS das nicht unbedingt empfiehlt und kann mit den Einschränkungen leben; bei vielen hier im Forum läuft das wohl ohne Probleme - man muss nur aufpassen welche Dienste man auf dem Server installiert).
Ich habe vor mit dem selbstsignierten Exchange Zertifikat zu arbeiten (schon deswg. weil ich auf dem Server keine Zertifizierungsstelle installieren will) - für ein kleines Büro ist dies aus meiner Sicht auch ausreichend.
Nun suche ich die optimale Konfiguration für die Anbindung der Clients.
Erfolgreich und ohne großen Stress konnte ich bisher leider nur die Anbindung über RPC over HTTP testen. Sprich bei der Einrichtung des Cients auf "weitere Einstellungen" und die Proxyeinstellungen konfigurieren:
Das Ganze scheint auf den ersten Blick auch zu funktionieren. Allerdings bekomme ich bei der Anzeige des Verbindungsstatus immer einen Fehler:
Ich bin mir nicht sicher, ob ich dadurch irgendwelche Einschränkungen habe - dieser 1 Fehler der immer angezeigt wird macht mir auf jeden Fall "angst". Wenn ich Outlook über Domänenmitglieder einrichte habe ich hier immer 0 bei Fehler stehen. Der Fehler ist nicht immer in der gleichen Zeile - manchmal ist er auch bei "Verzeichnis" vorhanden.
Zudem denke ich wäre eine verschlüsselte Verbindung (auch wenns nur im lokalen Netzwerk mehr oder weniger in dem kleinen Büro egal ist) wahrscheinlich besser.
Eine SSL Verbindung bekomme ich bei RPC over HTTPs aber nicht ohne Probleme hin - zumindest habe ich es nicht geschafft.
Noch besser wäre natürlch wenn alles wie bei Domänenmitgliedern (ohne RPC?) laufen würde - ich glaube aber, dass man das wg. des Zertifikats nicht hinbekommt, oder? (Hab viel ausprobiert aber bin leider nicht zu einem aktzeptablen Ergebnis gekommen).
Was ist aus Eurer Sicht die Beste Methode um nicht Domänenclients in meinem Fall an den Exchange anzubinden?
Für wertvolle Tipps und ggf. sogar einer guten Anleitung wäre ich sehr dankbar (im web kursieren sehr viele "Anleitungen" - u.a. mit Anpassung der hosts usw. bin mir aber nicht sicher was wirklich zuverlässig funktioniert und gut ist)
Viele Grüße,
Malungo
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 249950
Url: https://administrator.de/forum/exchange-2013-outlook-anbindung-von-nicht-domaenenmitglieder-249950.html
Ausgedruckt am: 27.12.2024 um 00:12 Uhr
12 Kommentare
Neuester Kommentar
Moin,
Normalerweiße reicht Outlook Anywhere aus.
Gruß,
Dani
P.S. Wenn du noch Autodiscover für Outlook Anywhere einführst, kannst du dir die manuelle Konfiguration sparen.
Erfolgreich und ohne großen Stress konnte ich bisher leider nur die Anbindung über RPC over HTTP testen
Welche Variante gibt es sonst noch? Outlook Anywhere baut auf RPC over HTTPs.Eine SSL Verbindung bekomme ich bei RPC over HTTPs aber nicht ohne Probleme hin - zumindest habe ich es nicht geschafft.
Was genau macht dir Probleme bei der Einrichtung? Wichtig wäre auf jeden Fall eine gekauftes SSL-Zertifikat. Gibt es ab 30€ für eine Domain. Was ist aus Eurer Sicht die Beste Methode um nicht Domänenclients in meinem Fall an den Exchange anzubinden?
Hängt vom Sicherheitsbedürfnis ab. Normalerweiße reicht Outlook Anywhere aus.Gruß,
Dani
P.S. Wenn du noch Autodiscover für Outlook Anywhere einführst, kannst du dir die manuelle Konfiguration sparen.
Zitat von @Dani:
Moin,
> Erfolgreich und ohne großen Stress konnte ich bisher leider nur die Anbindung über RPC over HTTP testen
Welche Variante gibt es sonst noch? Outlook Anywhere baut auf RPC over HTTPs.
Naja, die Lösung mit HTTPs; ich verwende aktuell ja nur HTTP; also ohne Verschlüsselung; oder eine Verbindung über ganz normales TCP/IP.Moin,
> Erfolgreich und ohne großen Stress konnte ich bisher leider nur die Anbindung über RPC over HTTP testen
Welche Variante gibt es sonst noch? Outlook Anywhere baut auf RPC over HTTPs.
Sorry, ich muss ehrlich sagen, dass ich hier noch zu wenig weiß. Geht außerhalb einer Domäne eine "normale" Anbindung an Exchange über TCP/IP nicht? Geht das nur via Outlook Anywhere (RPC over HTTP(s))?
> Eine SSL Verbindung bekomme ich bei RPC over HTTPs aber nicht ohne Probleme hin - zumindest habe ich es nicht geschafft.
Was genau macht dir Probleme bei der Einrichtung? Wichtig wäre auf jeden Fall eine gekauftes SSL-Zertifikat. Gibt es ab
30€ für eine Domain.
Ich habe es bisher nicht geschafft, dass der Client das Zertifikat akzeptiert. Gebe ich im Browser des nicht Domänenmitglieds den Exchange mit OWA oder ECP ein, erhalte ich die Warnung, dass der Gegenstelle nicht vertraut wird. Wenn ich die Clients manuell mit RPC over HTTPs verbinde, erscheint beim Outlookstart, dass keine Verbindung zum Exchange aufgebaut werden kann (nicht die Zertifikatswarnung, die ich wegklicken kann, wie ich es von einem Domänenmitglied kenne).Was genau macht dir Probleme bei der Einrichtung? Wichtig wäre auf jeden Fall eine gekauftes SSL-Zertifikat. Gibt es ab
30€ für eine Domain.
Ich vermute deshalb, dass der gescheiterte Verbindungsversuch des nicht Domänenmitglieds am Zertifikat liegt.
Wäre folgendes eine Abhilfe:
Am Server 2 Hyper-Vs; 1x mit DC/DNS/CA und 1x nur mit Exchange (wahrscheinlich auch die nachhaltigste Lösung) zu installieren.
Ist es möglich dem nicht Domänenmitglied beizubringen, dass er das selbsterstellte Zertifikat der CA akzeptiert?
Ich habe hier schon viel probiert, bin aber nicht zu einem Ergebnis gekommen.
Mein letzter Versuch war in einer Testumgebung DC, DNS, Exchange UND CA auf einem System zu installieren.
Bzgl. CA hatte ich die Zertifizierungstelle und den Zertifizierungswebdienst installiert. Hier habe ich aber nach div. Versuchen immer die Meldung erhalten, dass der Client keine Verbindung zur Zeritifzierungsstelle aufbauen kann, und das Zertifikat deshalb als ungültig angesehen wurde.
Anschließend habe ich dann versucht den Rollendienst "Zertifikatregistrierungs-Webdienst" zu installieren, weil ich mir dadurch Abhilfe erhoffte. Leider hat mir dass dann den Exchange irgendwie zerschossen (kein Zugriff mehr aufs Webinterface...)
> Was ist aus Eurer Sicht die Beste Methode um nicht Domänenclients in meinem Fall an den Exchange anzubinden?
Hängt vom Sicherheitsbedürfnis ab. Normalerweiße reicht Outlook Anywhere aus.
Ich sehe das Sicherheitsbedürfnis im LAN für das Büro nicht allzu groß an Hängt vom Sicherheitsbedürfnis ab.
Normalerweiße reicht Outlook Anywhere aus.
Gruß,
Dani
P.S. Wenn du noch Autodiscover für Outlook Anywhere einführst, kannst du dir die manuelle Konfiguration sparen.
Moin,
1. Server: DC + DNS
2. Server: Exchange
3. Server: CA.
Du solltest vorher unbedingt immer die Technet-Artikel zum entsptechendem Lesen bevor du irgendwas planst oder konfigurierst.
Gruß,
Dani
Geht außerhalb einer Domäne eine "normale" Anbindung an Exchange über TCP/IP nicht? Geht das nur via Outlook Anywhere (RPC over HTTP(s))?
Was ist HTTP(s)? Richtig eine TCP/IP-Protokoll. Ich habe es bisher nicht geschafft, dass der Client das Zertifikat akzeptiert.
Client-Zertifikat? Du meinst das Serverzertifikat. Ist dieses selbstsigniert oder gekauft? Das gekaufte Zertifikat macht es für mich bei Adminitration, Konfiguration und Fehlersuche einfacher. Die 30€/Jahr sind gut investiert.Wenn ich die Clients manuell mit RPC over HTTPs verbinde, erscheint beim Outlookstart, dass keine Verbindung zum Exchange aufgebaut werden kann (nicht die Zertifikatswarnung, die ich wegklicken kann, wie ich es von einem Domänenmitglied kenne).
Wegklicken ist grundsätzlich eine schlechte Idee. Das Ganze muss ohne Fehlermeldung von Anfang bis Ende durchlaufen. Ist es möglich dem nicht Domänenmitglied beizubringen, dass er das selbsterstellte Zertifikat der CA akzeptiert?
Natürlich. Du musst das CA-Root-Zertifikat auf dem Client in den Zertifikaten unter Stammzertifizierungsstellen importieren. Danach wird jedes Zertifikat, dass von dieser ausgestellt wurde, als gültig angesehen. Bitte denke aber daran, sobald der Rechner neuinstalliert wird ohne das CA-Root-Zertifikat abgeschlaufen ist, du überall manuell eingreifen musst. Da sind die 30€ schnell kompensiert. Mein letzter Versuch war in einer Testumgebung DC, DNS, Exchange UND CA auf einem System zu installieren.
Das kannst du ganz schnell vergessen. Das geht nach hinten los.1. Server: DC + DNS
2. Server: Exchange
3. Server: CA.
Du solltest vorher unbedingt immer die Technet-Artikel zum entsptechendem Lesen bevor du irgendwas planst oder konfigurierst.
Bisher habe ich mit RPC over HTTP festgestellt, dass die Pflege des Abwesenheitsagenten nicht funktioniert (keine Verbindung zum Exchange möglich); das liegt aber wohl auch am Autodiscover, oder?
Nö. Das muss funktioniert problemlos. Könnte an der Konfiguration liegen. Lässt sich aus meiner Sicht schwer eingrenzen, da du einige Baustellen offen hast.Gruß,
Dani
Zitat von @Dani:
Moin,
> Geht außerhalb einer Domäne eine "normale" Anbindung an Exchange über TCP/IP nicht? Geht das nur
via Outlook Anywhere (RPC over HTTP(s))?
Was ist HTTP(s)? Richtig eine TCP/IP-Protokoll.
Ok, vll. hab ich mich blöd ausgedrückt:Moin,
> Geht außerhalb einer Domäne eine "normale" Anbindung an Exchange über TCP/IP nicht? Geht das nur
via Outlook Anywhere (RPC over HTTP(s))?
Was ist HTTP(s)? Richtig eine TCP/IP-Protokoll.
Wenn ich bei nem Outlook 2010 Client der in der Domäne ist und an Exchange (zumindest 2010) angebunden ist, den Verbindungsstatus ansehe, dann steht hier nicht wie in meinem Screenshot HTTP sondern TCP/IP.
Daher schließe ich, dass mein nicht Domänenmitglied anders verbunden ist (Outlook Anywhere) als mein Domänenmitglied (MAPI, oder?).
Ist es möglich oder nötig meine im lokal befindlichen nicht Domänenmitglieder mit MAPI anzubinden? Also gibt es Nachteile?
Eines der beiden Protokolle könnte ich dann im Exchangeadmin deaktivieren...
> Ich habe es bisher nicht geschafft, dass der Client das Zertifikat akzeptiert.
Client-Zertifikat? Du meinst das Serverzertifikat. Ist dieses selbstsigniert oder gekauft? Das gekaufte Zertifikat macht es
für mich bei Adminitration, Konfiguration und Fehlersuche einfacher. Die 30€/Jahr sind gut investiert.
Du hast recht, ich meine das Serverzertifikat. Weder mit dem selbstsignierten, das bei der Exchange Installation generiert wird, noch mit einem selbst erstellten nach installation der CA (kann aber gut sein, dass ich hier irgendwo nen Fehler gemacht habe) hat es bei mir geklappt.Client-Zertifikat? Du meinst das Serverzertifikat. Ist dieses selbstsigniert oder gekauft? Das gekaufte Zertifikat macht es
für mich bei Adminitration, Konfiguration und Fehlersuche einfacher. Die 30€/Jahr sind gut investiert.
> Wenn ich die Clients manuell mit RPC over HTTPs verbinde, erscheint beim Outlookstart, dass keine Verbindung zum Exchange
aufgebaut werden kann (nicht die Zertifikatswarnung, die ich wegklicken kann, wie ich es von einem Domänenmitglied kenne).
Wegklicken ist grundsätzlich eine schlechte Idee. Das Ganze muss ohne Fehlermeldung von Anfang bis Ende durchlaufen.
sehe ich ein, das ist mein Ziel.aufgebaut werden kann (nicht die Zertifikatswarnung, die ich wegklicken kann, wie ich es von einem Domänenmitglied kenne).
Wegklicken ist grundsätzlich eine schlechte Idee. Das Ganze muss ohne Fehlermeldung von Anfang bis Ende durchlaufen.
> Ist es möglich dem nicht Domänenmitglied beizubringen, dass er das selbsterstellte Zertifikat der CA akzeptiert?
Natürlich. Du musst das CA-Root-Zertifikat auf dem Client in den Zertifikaten unter Stammzertifizierungsstellen importieren.
Danach wird jedes Zertifikat, dass von dieser ausgestellt wurde, als gültig angesehen. Bitte denke aber daran, sobald der
Rechner neuinstalliert wird ohne das CA-Root-Zertifikat abgeschlaufen ist, du überall manuell eingreifen musst. Da sind die
30€ schnell kompensiert.
Das habe ich noch nicht ganz verstanden, aber kann ich mir hoffentlich noch ergoogeln.Natürlich. Du musst das CA-Root-Zertifikat auf dem Client in den Zertifikaten unter Stammzertifizierungsstellen importieren.
Danach wird jedes Zertifikat, dass von dieser ausgestellt wurde, als gültig angesehen. Bitte denke aber daran, sobald der
Rechner neuinstalliert wird ohne das CA-Root-Zertifikat abgeschlaufen ist, du überall manuell eingreifen musst. Da sind die
30€ schnell kompensiert.
> Mein letzter Versuch war in einer Testumgebung DC, DNS, Exchange UND CA auf einem System zu installieren.
Das kannst du ganz schnell vergessen. Das geht nach hinten los.
1. Server: DC + DNS
2. Server: Exchange
3. Server: CA.
Du solltest vorher unbedingt immer die Technet-Artikel zum entsptechendem Lesen bevor du irgendwas planst oder konfigurierst.
fail Das kannst du ganz schnell vergessen. Das geht nach hinten los.
1. Server: DC + DNS
2. Server: Exchange
3. Server: CA.
Du solltest vorher unbedingt immer die Technet-Artikel zum entsptechendem Lesen bevor du irgendwas planst oder konfigurierst.
Danke für den Hinweis.Für ein kleines Büro wäre dann Hyper V mit 1x DC+DNS und 1x Exchange + gekauften Zertifikat am Besten, oder?
3. Server mit CA geht ja wieder in die Kosten da zum einem mehr Hardware und zum anderen die 2012R2 Standard Lizenz nur 2x Hyper V erlaubt...d.h. es wären zusätzliche Lizenzen möglich.
Kannst Du mir einen Hinweis geben, wo ich ein Zertifikat kaufen kann (seriös, günstig und zuverlässig?)
Wobei ich irgendwie immer noch nicht 100%ig davon überzeug davon bin, dass ich für meinen Fall (kleines Büro) unbedingt eine SSL Verschlüsselung also Zertifikat benötige? Lokal kann ich doch unverschlüsselt mit HTTP arbeiten; Für Active Sync kann ich das selbstsignierte vom Exchange verwenden - beim einrichten am Handy erscheint nur zu Beginn die Warnung mit dem Zertifikat - anschließend werden die Daten ja verschlüsselt übertragen. Dem Zertifikat kann ich vertrauen, weil ich ja weiß, dass es von meinem Exchange kommt.
Gerne würde ich es wie hier beschrieben machen:
http://www.exchange2010.at/archive/2011/07/10/zertifikat-oder-nicht-zer ...
nur mit dem Unterschied, dass die Clients NICHT in der Domäne sind. Das muss doch machbar und für den Zweck auch in Ordnung sein, oder?
> Bisher habe ich mit RPC over HTTP festgestellt, dass die Pflege des Abwesenheitsagenten nicht funktioniert (keine Verbindung
zum Exchange möglich); das liegt aber wohl auch am Autodiscover, oder?
Nö. Das muss funktioniert problemlos. Könnte an der Konfiguration liegen. Lässt sich aus meiner Sicht schwer
eingrenzen, da du einige Baustellen offen hast.
OK - Vielen DANK!!! Ich versuche die anderen Baustellen zu schließen und mich dann um das Thema zu kümmern...bzw. läuft es anschl. eh einwandfrei.zum Exchange möglich); das liegt aber wohl auch am Autodiscover, oder?
Nö. Das muss funktioniert problemlos. Könnte an der Konfiguration liegen. Lässt sich aus meiner Sicht schwer
eingrenzen, da du einige Baustellen offen hast.
Gruß,
Dani
Eines der beiden Protokolle könnte ich dann im Exchangeadmin deaktivieren...
Beschäftige dich nicht mit Nebensächlichkeiten. Das macht den Exchange nicht unsicherer.Daher schließe ich, dass mein nicht Domänenmitglied anders verbunden ist (Outlook Anywhere) als mein Domänenmitglied (MAPI, oder?).
Nein, das hängt davon ab, ob der Rechner im LAN oder über das Internet die Verbindung herstellt.Für ein kleines Büro wäre dann Hyper V mit 1x DC+DNS und 1x Exchange + gekauften Zertifikat am Besten, oder?
Völlig richtig! Vergiss die CA... hast schon genug Zeit investiert und das Zicke auf Smartphone & Co. kannst du verzichten. Schau dich mal bei Hosteurope oder domainFactory um.Wobei ich irgendwie immer noch nicht 100%ig davon überzeug davon bin, dass ich für meinen Fall (kleines Büro) unbedingt eine SSL Verschlüsselung also Zertifikat benötige?
Du machst dir zu viele Gedanken. Richte es einfach wie vom Hersteller gedacht ein und es wird laufen ohne Probleme. Anpassungen an der Konfiguration kann früher oder später Probleme machen. Halte dich an die Standards von Microsoft. Richte es ein und Active Sync, Outlook Anywhere und OWA laufen in wenigen Minuten wie gedacht. Als Luxus noch Autodiscover und deine Kollegen sind gülcklich.Gruß
Dani
Zitat von @Dani:
> Für ein kleines Büro wäre dann Hyper V mit 1x DC+DNS und 1x Exchange + gekauften Zertifikat am Besten, oder?
Völlig richtig! Vergiss die CA... hast schon genug Zeit investiert und das Zicke auf Smartphone & Co. kannst du
verzichten. Schau dich mal bei Hosteurope oder domainFactory um.
d.h. es würde das "kleinste" SSL Zertifikat von Hosteurope> Für ein kleines Büro wäre dann Hyper V mit 1x DC+DNS und 1x Exchange + gekauften Zertifikat am Besten, oder?
Völlig richtig! Vergiss die CA... hast schon genug Zeit investiert und das Zicke auf Smartphone & Co. kannst du
verzichten. Schau dich mal bei Hosteurope oder domainFactory um.
https://www.hosteurope.de/Server/Addons/SSL-Zertifikate/Host-Europe-SSL/
für jährlich 30€
bzw. das von df
http://www.df.eu/de/ssl-zertifikate/produktdetails/
rapidSSL für 1,99€/Monat
ausreichen,oder?
Bei beiden kann ich dann für meinen Exchangeserver (w2012-exchange.mydomain.local) ein Zertifikat ausstellen, dass ich in der Exchangeverwaltungsconsole installiere und bei den nicht Domänenmitgliedern bei den Vertrauenwürdigen Stammzeritifikaten installiere?
Für die statische IP (für Zugriff über ActiveSync) brauche ich kein eigenes Zertifikat, weil ich hier beim einrichten die Warnung einmal bestätige und das Ganze dann reibungslos läuft?
(Sorry der blöden Nachfrage, aber ich habe hier im Forum auch schon von Fällen gelesen, die das Zertifikat für die falsche Domain oder den falschen Host ausgestellt hatten...)
> Wobei ich irgendwie immer noch nicht 100%ig davon überzeug davon bin, dass ich für meinen Fall (kleines Büro)
unbedingt eine SSL Verschlüsselung also Zertifikat benötige?
Du machst dir zu viele Gedanken. Richte es einfach wie vom Hersteller gedacht ein und es wird laufen ohne Probleme. Anpassungen an
der Konfiguration kann früher oder später Probleme machen. Halte dich an die Standards von Microsoft. Richte es ein und
Active Sync, Outlook Anywhere und OWA laufen in wenigen Minuten wie gedacht. Als Luxus noch Autodiscover und deine Kollegen sind
gülcklich.
Danke - das macht mir wieder Mut unbedingt eine SSL Verschlüsselung also Zertifikat benötige?
Du machst dir zu viele Gedanken. Richte es einfach wie vom Hersteller gedacht ein und es wird laufen ohne Probleme. Anpassungen an
der Konfiguration kann früher oder später Probleme machen. Halte dich an die Standards von Microsoft. Richte es ein und
Active Sync, Outlook Anywhere und OWA laufen in wenigen Minuten wie gedacht. Als Luxus noch Autodiscover und deine Kollegen sind
gülcklich.
Gruß
Dani
Moin,
bei HostEurope erhältst du gleich ein fertiges PKCS#12 Zertifikat, dass du einfach einspielen kannst.
Gruß,
Dani
bei HostEurope erhältst du gleich ein fertiges PKCS#12 Zertifikat, dass du einfach einspielen kannst.
Bei beiden kann ich dann für meinen Exchangeserver (w2012-exchange.mydomain.local) ein Zertifikat ausstellen, dass ich in der Exchangeverwaltungsconsole
Nein, du importierst das Zertifikat auf dem Exchange-Server und aktivierst dieses.bei den nicht Domänenmitgliedern bei den Vertrauenwürdigen Stammzeritifikaten installiere?
Brauchst du nicht. Da die Vertauenswürdige Stammzertifizierungstellen meistens schon im Betriebssystem integriert sind. Bei Windows-Systemen noch nie Probleme gehabt.Für die statische IP (für Zugriff über ActiveSync) brauche ich kein eigenes Zertifikat, weil ich hier beim einrichten die Warnung einmal bestätige und das Ganze dann reibungslos läuft?
Du musst das Zertifikat auf einen Domainname ausstellen, z.B. exchange.deinedomain.de. Somit musst du auch sicherstellen, dass es diesen Eintrag (A-Record) im DNS-Server gibt oder ggf. anlegst. Als Ziel nimmst du natürlich deine statische IP-Adresse. Bei deinem ISP hinterlegst du für den Reverse-DNS-Eintrag ebenfalls exchange.deinedomain.de.Gruß,
Dani
alles klar!
Vielen Dank, Dani,
Gruß,
Malungo
Vielen Dank, Dani,
Gruß,
Malungo
> Für die statische IP (für Zugriff über ActiveSync) brauche ich kein eigenes Zertifikat, weil ich hier beim
einrichten die Warnung einmal bestätige und das Ganze dann reibungslos läuft?
Du musst das Zertifikat auf einen Domainname ausstellen, z.B. exchange.deinedomain.de. Somit musst du auch sicherstellen, dass es
diesen Eintrag (A-Record) im DNS-Server gibt oder ggf. anlegst. Als Ziel nimmst du natürlich deine statische IP-Adresse. Bei
deinem ISP hinterlegst du für den Reverse-DNS-Eintrag ebenfalls exchange.deinedomain.de.
einrichten die Warnung einmal bestätige und das Ganze dann reibungslos läuft?
Du musst das Zertifikat auf einen Domainname ausstellen, z.B. exchange.deinedomain.de. Somit musst du auch sicherstellen, dass es
diesen Eintrag (A-Record) im DNS-Server gibt oder ggf. anlegst. Als Ziel nimmst du natürlich deine statische IP-Adresse. Bei
deinem ISP hinterlegst du für den Reverse-DNS-Eintrag ebenfalls exchange.deinedomain.de.
sorry, bei der praktischen Umsetzung ergeben sich jetzt doch noch Fragen:
Auf meinem 1. Hyper-V läuft ja AD und DNS. Die AD Domain nennt sich xyz.local; hierfür ist auch der DNS Server eingerichtet.
Die Domain für den ich den Exchange verwende nennt sich xyz.com.
Bin mir nicht ganz sicher, ob die AD Domain nicht doch gleich der externen Domain (xyz) nennen soll. Hab u.a. hier nachgelesen: http://www.msxfaq.de/konzepte/dns.htm (VOIP/SIP will ich aber gar nicht nutzten => es muss .local eigentlich reichen?)
Wenn die doch identisch sein sollen muss ich meine 2 HyperVs nochmal vollständig neu aufsetzen.
Mein ISP hat mit meinem Provider (1&1) bei dem ich die Domain (xyz.com) gehostet habe nichts zu tun.
Eigentlich dachte ich, ich erstelle bei 1&1 eine subdomain für xyz.com also z.B. exchange.xyz.com und ordne dieser Subdomain die statische IP-Adresse meines ISP zu. Da mein Zertifikat für exchange.xyz.com ausgestellt wurde, dürfte ich hier kein SSL Problem bei einer Verbindung über ActiveSync bekommen. Oder hätte ich noch eine andere Möglichkeit?
Du schreibst, dass ich einen Eintrag im DNS Server anlegen soll?
Sprich eine neue Forward-Lookupzone für xyz.com mit einem Host exchange mit der lokalen IP des Exchangeservers (damit der Name für das Zertifikat passt)? Damit auch die Website usw. noch von intern erreichbar ist, trage ich für den host www.xyz.com die externe IP welche zur Website des Providers führt ein. Damit es auch ohne www funktioniert erstelle ich noch einen Host (a) mit der IP zur Website (identisch übergeordnetem Ordner).
Habe ich das richtig verstanden? Alterntiv könnte man auch die hosts der clients anpassen - aber im DNS ists natürlich komfortabler, wenn ich mit der Einstellung keine Probleme zu erwarten habe.
Zudem schreibst Du ich soll beim ISP einen Reverse-Eintrag mit exchange.xyz.com erstellen. Zur statischen IP habe ich bereits einen reverse-Eintrag des ISP; der aber natürlich nicht exchange.xyz.com heißt. Kann nicht auch dieser verwendet werden (ich habe gelesen, dass die Mailserver nur verlangen, dass ein reverse Eintrag existiert; muss dieser zwingend exchange.xyz.com heißen?)
Oder liege ich mit meiner o.g. Annahme richtig bzgl. der Subdomain die ich bereits angelegt habe? Wie sonst könnte ich via ActiveSync ohne Zertifikatswarnung auf den Exchange zugreifen?
Wenn ich richtig recherchiert habe ist der Reverse-Eintrag notwendig, damit andere Mailserver meine Mails auch zuverlässig annehmen - und diese nicht als Spam behandelt werden.
Muss ich mir darüber überhaupt den Kopf zerbrechen wenn ich die Mails via 1&1 Smarthost versende?
...wahrscheinlich denke ich schon wieder zu kompliziert?
Viele Grüße,
Malungo
Moin,
Gruß,
Dani
Bin mir nicht ganz sicher, ob die AD Domain nicht doch gleich der externen Domain (xyz) nennen soll. Hab u.a. hier nachgelesen: http://www.msxfaq.de/konzepte/dns.htm (VOIP/SIP will ich aber gar nicht nutzten => es muss .local eigentlich reichen?)
Wenn du deine Windows-Domöne gleich nennst als die Internetdomäne, musst du SplitDNS in Zukunft konfigurieren. Funktioniert auch, man sollte aber wissen was man macht. Daher den Vorschlag für die Windows-Domäne ad.xyz.de zu nehmen.Des Weiteren ist die Endung .local nicht mehr Best Practise seitens Microsoft und wird für MulticastDNS genutzt. Daher bei neuen Umgebungen daran denken! Ein Domain-Rename bei vorhandenen Exchange-Server ist nicht mehr möglich.Daher bleibt nur eine Migration übrig oder eine komplette Neuinstallation.(VOIP/SIP will ich aber gar nicht nutzten => es muss .local eigentlich reichen?)
Denk einfach über den Tellerrand hinaus. Was ist 3-5 Jahren?Eigentlich dachte ich, ich erstelle bei 1&1 eine subdomain für xyz.com also z.B. exchange.xyz.com und ordne dieser Subdomain die statische IP-Adresse meines ISP zu. Da mein Zertifikat für exchange.xyz.com ausgestellt wurde, dürfte ich hier kein SSL Problem bei einer Verbindung über ActiveSync bekommen. Oder hätte ich noch eine andere Möglichkeit?
Du bist auf dem richtigen Weg.Sprich eine neue Forward-Lookupzone für xyz.com mit einem Host exchange mit der lokalen IP des Exchangeservers
Nein, ich meinte damit deinen Gedanken einen Absatz höher. Bloß keine DNS-Zone auf dem Windows Domain Controller anlegen.Kann nicht auch dieser verwendet werden (ich habe gelesen, dass die Mailserver nur verlangen, dass ein reverse Eintrag existiert; muss dieser zwingend exchange.xyz.com heißen?)
Kannst du. Wenn's 100% sein soll, den Reverse-Eintrag auf exchange.xyz.com setzen. Mit MX Lookup Tool kannst du deine Konfiguration nochmals prüfen lassen.Muss ich mir darüber überhaupt den Kopf zerbrechen wenn ich die Mails via 1&1 Smarthost versende?
Wie empfängst du E-Mails, auch über dem Smarthost? Ich bevorzuge immer den direkten Versand von E-Mails, wenn das möglich ist. Somit muss ich mich nicht auf Dritte verlassen. Gruß,
Dani
Zitat von @Dani:
> Sprich eine neue Forward-Lookupzone für xyz.com mit einem Host exchange mit der lokalen IP des Exchangeservers
Nein, ich meinte damit deinen Gedanken einen Absatz höher. Bloß keine DNS-Zone auf dem Windows Domain Controller
anlegen.
ok, aber wie kann ich dann meinen Clients beibringen, dass exchange.xyz.com über die interne IP-Adresse erreichbar ist - ohne dass ich im DNS die Zone der externen Domain abbilde?> Sprich eine neue Forward-Lookupzone für xyz.com mit einem Host exchange mit der lokalen IP des Exchangeservers
Nein, ich meinte damit deinen Gedanken einen Absatz höher. Bloß keine DNS-Zone auf dem Windows Domain Controller
anlegen.
Macht man das wirklich nur über die hosts-Datei auf allen Clients?
In meinem Testbetrieb hat die Abbildung der eigenen Zone eigentlich gut funktioniert (ok, der Exchange war hier nicht wirklich extern zum Empfangen angebunden) - wahrscheinlich würde es im Echtbetrieb dann zu Problemen kommen (die ich aktuell noch nicht kenne)
Guten Abend,
Gruß,
Dani
ok, aber wie kann ich dann meinen Clients beibringen, dass exchange.xyz.com über die interne IP-Adresse erreichbar ist - ohne dass ich im DNS die Zone der externen Domain abbilde?
Das Zauberwort heißt "NAT-Reflection". Dieses Funktion unterstützt eigentlich jeder gescheite Router. Damit können auch die Clients problemlos den Exchangeserver finden, ohne Zertifikatswarnung und Fehlermeldungen. Somit bleibt die DNS-Zone sauber und evtl. Fehlerquellen werden vermieden.Macht man das wirklich nur über die hosts-Datei auf allen Clients?
Setzen Sechs! Warum gibt es in einer Domäne einen DNS-Server?Gruß,
Dani
