Exchange Client INTERN via RPCoverHTTP anbinden
Hallo zusammen,
ich habe folgende Aufgabe:
ich habe einen Exchange 2010 SP2 (gleichzeitig DNS, DC) ohne feste IP (mit xxx.dyndns.org).
Domäne: privat.yyy
Exchange Server: mailer.privat.yyy
OWA ist OHNE Zertifikatsfehler aufrufbar (intern als auch extern)!
Ist es möglich Outlook-Clients, die nicht Mitglied der Domäne sind, rein INTERN(!) anzubinden?
Also ich meine damit ohne Angabe des HTTP-Proxys xxx.dyndns.org.
Weil sonst läuft der ganze Traffic ja übers Internet, oder?
Das ist ziemlich zäh!
Also eine rein interne Anbindung via RPC-over-HTTP - geht das?
Welche Einstellungen muss ich da am CLient machen?
Gruß
duffy6
ich habe folgende Aufgabe:
ich habe einen Exchange 2010 SP2 (gleichzeitig DNS, DC) ohne feste IP (mit xxx.dyndns.org).
Domäne: privat.yyy
Exchange Server: mailer.privat.yyy
OWA ist OHNE Zertifikatsfehler aufrufbar (intern als auch extern)!
Ist es möglich Outlook-Clients, die nicht Mitglied der Domäne sind, rein INTERN(!) anzubinden?
Also ich meine damit ohne Angabe des HTTP-Proxys xxx.dyndns.org.
Weil sonst läuft der ganze Traffic ja übers Internet, oder?
Das ist ziemlich zäh!
Also eine rein interne Anbindung via RPC-over-HTTP - geht das?
Welche Einstellungen muss ich da am CLient machen?
Gruß
duffy6
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 197886
Url: https://administrator.de/contentid/197886
Ausgedruckt am: 22.11.2024 um 03:11 Uhr
10 Kommentare
Neuester Kommentar
Hallo,
du kannst auch von nicht-domänen-Clients "ganz normales" Outlook (also MAPI direkt, ohne HTTPS-Tunnel) verwenden, es werden dann beim Start Nutzername & Kennwort abgefragt. Die Konfiguration ist ansonsten die gleiche. Das RPC-over-HTTPS/Outlook Anywhere kapselt die MAPI-Aufrufe lediglich in einen HTTPS-Tunnel, der sich auf Firewalls viel leichter freischalten lässt, als der ungekapselte MAPI-Traffic.
Was Outlook ab 2007 generell braucht, ist funktionierendes Autodiscover. Sonst kannst zu zwar Mails senden & empfangen, scheiterst aber beim Abruf von Free&Busy und setzen von Regeln (-> OOF). Für Domänenclients ist das kein Thema: Exchange legt bei der Installtion (und bei Konfigurationsänderungen) einen entsprechenden SCP (Service Connection Point, "irgendein" Eintrag im AD) an. Nicht-Domänenclients können darauf nicht zugreifen, deswegen muss man sich hier Gedanken über die alternativen Discover-Methoden machen (am einfachsten (m.E.) SRV-Records).
Wenn du intern unbedingt Outlook Anywhere verwenden willst (wie gesagt: ist erstmal nicht nötig) geht das auch. Bis Outlook 2003 trägst du bei "Exchange-Proxy" einfach den internen Namen des Exchange-Servers ein (dieser muss dazu in dem Zertifikat enthalten sein - wenn du schreibst "owa intern geht" gehe ich davon aus, dass das der Fall ist, und du für OWA auch den internen Exchange-Hostname verwendest). Ab Outlook 2007 kannst du diesen Eintrag auch machen, aber brauchst wie oben geschrieben eh Autodiscover. Der benötigte interne Hostname wird von Autodiscover glaube ich automatisch publiziert. Aber: Outlook wählt im Zweifelsfall einfach aus, was am besten funktioniert (MAPI direkt oder Outlook Anywhere), d.h. du kannst das gar nicht fest vorgeben.
Gruß
Filipp
Edit: Notiz an mich selbst: nach einem langen Tag um die Uhrzeit keine Beiträge mehr schreiben. Alle Aussagen halte ich für richtig, aber ich muss zugeben, dass der Beitrag nicht unbedingt mit Klarheit grenzt - du solltest spätestens nach dem zweiten Absatz aufhören zu lesen
du kannst auch von nicht-domänen-Clients "ganz normales" Outlook (also MAPI direkt, ohne HTTPS-Tunnel) verwenden, es werden dann beim Start Nutzername & Kennwort abgefragt. Die Konfiguration ist ansonsten die gleiche. Das RPC-over-HTTPS/Outlook Anywhere kapselt die MAPI-Aufrufe lediglich in einen HTTPS-Tunnel, der sich auf Firewalls viel leichter freischalten lässt, als der ungekapselte MAPI-Traffic.
Was Outlook ab 2007 generell braucht, ist funktionierendes Autodiscover. Sonst kannst zu zwar Mails senden & empfangen, scheiterst aber beim Abruf von Free&Busy und setzen von Regeln (-> OOF). Für Domänenclients ist das kein Thema: Exchange legt bei der Installtion (und bei Konfigurationsänderungen) einen entsprechenden SCP (Service Connection Point, "irgendein" Eintrag im AD) an. Nicht-Domänenclients können darauf nicht zugreifen, deswegen muss man sich hier Gedanken über die alternativen Discover-Methoden machen (am einfachsten (m.E.) SRV-Records).
Wenn du intern unbedingt Outlook Anywhere verwenden willst (wie gesagt: ist erstmal nicht nötig) geht das auch. Bis Outlook 2003 trägst du bei "Exchange-Proxy" einfach den internen Namen des Exchange-Servers ein (dieser muss dazu in dem Zertifikat enthalten sein - wenn du schreibst "owa intern geht" gehe ich davon aus, dass das der Fall ist, und du für OWA auch den internen Exchange-Hostname verwendest). Ab Outlook 2007 kannst du diesen Eintrag auch machen, aber brauchst wie oben geschrieben eh Autodiscover. Der benötigte interne Hostname wird von Autodiscover glaube ich automatisch publiziert. Aber: Outlook wählt im Zweifelsfall einfach aus, was am besten funktioniert (MAPI direkt oder Outlook Anywhere), d.h. du kannst das gar nicht fest vorgeben.
Gruß
Filipp
Edit: Notiz an mich selbst: nach einem langen Tag um die Uhrzeit keine Beiträge mehr schreiben. Alle Aussagen halte ich für richtig, aber ich muss zugeben, dass der Beitrag nicht unbedingt mit Klarheit grenzt - du solltest spätestens nach dem zweiten Absatz aufhören zu lesen
Hi.
Hier hast du sowieso eine Fehlkonfiguration in deinem System. Exchange benötigt Active Directory. Und Active Directory benötigt wiederum einen DNS. Und die Einträge die im Windows DNS vorhanden sind, kann die Fritz Box nicht abbilden.
LG Günther
Die Clients erhalten Ihre IP und den DNS-Server von der Fritzbox.
Hier hast du sowieso eine Fehlkonfiguration in deinem System. Exchange benötigt Active Directory. Und Active Directory benötigt wiederum einen DNS. Und die Einträge die im Windows DNS vorhanden sind, kann die Fritz Box nicht abbilden.
LG Günther
Hallo,
Du willst doch nur Mails Intern mit Outlook Clients welche auf Rechner laufen die nicht Mitglied deiner Domäne sind auf den Exchange per RPC over HTTP zugreifen lassen, oder auch von extern?
Gruß,
Peter
[Nachtrag]
War zulange weg weil Bier holen. GuentherH war schneller
[/Nachtrag]
Zitat von @duffy6:
Mir ist noch eine wichtige Information zum Netzwerk eingefallen, die ich oben nicht erwähnt hatte:
Warum erst immer hinterher?Mir ist noch eine wichtige Information zum Netzwerk eingefallen, die ich oben nicht erwähnt hatte:
Die Clients erhalten Ihre IP und den DNS-Server von der Fritzbox.
Das ist ein NoGo. Warum? Zum einen weil die FritzBox nur DNS Weiterleitung macht und keinen DNS Server darstellt. Zum anderen weil du eben weil es kein DNS Server ist du dort dein AD und die für ein AD zwingend notwendigen Eintragungen dort gar nicht erst machen kannst. Wenn du ein AD nutzt musst du auch ein DNS in deinem AD nutzen. Nutze daher den DNS auf deinen DC. Dazu ist er da. Dort eine Weiterleitung für alles andere eintragen. Und nutze den DHCP deines DC ebenfalls, der kann nämlich alle Optionen die die in deinem AD (Netz) brauchst den Clients übergeben. Auf den Clients ist zwingend dein DNS (auf den DC) einzutragen (per DHCP).>ping mailer
Mailer ist kein FQDN. Soll das der NETBIOS Name sein? Und deine FritzBox kann den auch nicht kennen weil die ihre eigene Erweiterung dran hängt. DNS auf deinen Server verwenden. Und wenn du mit NETBIOS namen arbneiten willst, überlege dir den WINS anzuschmeißen.>ping mailer.privat.yyy
Ist das ein Externer Name? Wie nennt sich deine Interne Domäne? Soll deine FritzBox auf Ping anfragen aus dem Internet nicht Antworten oder ist das nicht deine IP?>ping autodiscover.privat.yyy
Intern oder Externer Name?Geht mein Vorhaben mit dem DNS-Server der Fritzbox?
Die FritzBox hat keine DNS Server, nur DNS Cache und Weiterleitung. Nutze den DNS deines DC (dazu ist er da und wurde auch beim einrichten deines DC Installiert und Konfiguriert bis auf die Weiterleitung)Und welche Daten muss ich beim CLient in der Exchange Konten Konfiguration dann eintragen?
Nutzt du den gleichen Domänen Namen Intern wie extern und versuchst immer noch als Absender *,gmx.de zu versenden wie hier von dir angegeben?Du willst doch nur Mails Intern mit Outlook Clients welche auf Rechner laufen die nicht Mitglied deiner Domäne sind auf den Exchange per RPC over HTTP zugreifen lassen, oder auch von extern?
Gruß,
Peter
[Nachtrag]
War zulange weg weil Bier holen. GuentherH war schneller
[/Nachtrag]
Hallo,
Brrrr. Mach den DC zum DNS und DHCP. Nutze diesen (auch für nicht Domänen Clients in deinem LAN/WLAN). Das wird dir alles erleichtern und spart dir diese frickelei mit den Eintragungen. Glaub uns, es ist ein bastelei was du dort machst. Dein DC bringt alles mit was du benötigts. Die FritzBox ist nicht dein DHCP und nicht dein DNS (Server).
Gruß,
Peter
Brrrr. Mach den DC zum DNS und DHCP. Nutze diesen (auch für nicht Domänen Clients in deinem LAN/WLAN). Das wird dir alles erleichtern und spart dir diese frickelei mit den Eintragungen. Glaub uns, es ist ein bastelei was du dort machst. Dein DC bringt alles mit was du benötigts. Die FritzBox ist nicht dein DHCP und nicht dein DNS (Server).
Ist das problematisch?
Nein. Getrennte Namen ist gut.Was mir aufgefallen ist: durch die Portweiterleitung 443 im Router auf den Exchange/DC/DNS/Certsrv
Es gibt schon gründe warum ein Exchange eben nicht DC sein soll. Solange du alles auf einer Maschine hast (und es eben kein SBS ist) hast du große Probleme zu erwarten. Ist ein SBS 2011 für dich nicht besser geeignet?Ist das ein Sicherheitsrisiko
Natürlich, ganz klar ein JA.und kann falls ja, welche Dienste muss/sollte ich deaktivieren
Nun, welche Dienste brauchst du denn nicht? Exchange? Certsrv? DC? DNS? DHCP? usw. usw. usw. bzw. die Firewall konfigurieren?
Das geschieht normalerweise schon durch die entsprechenden Programme. Wenn allerdings du dort selbst .... Warum keine UTM davor setzen? Für privat und Firmen sogar Kostenlos von Sophos zu erhalten wobei für Privat alle Module enthalten sind. Damit ist auch ein Reverse Proxy (WAF) etc. alles schon drin. http://www.sophos.com/de-de/products/free-tools/sophos-utm-home-edition ...Gruß,
Peter
Hallo,
Sicherheit ist immer Relativ. 100%ige Sicherheit ist nur wenn du kein Internet nutzt und keiner an den Server dran kommt Eine Firewall oder gar eine UTM vor dem netz ist immer besser als einen Server direkt ins Internet zu stellen.
Ein SBS hat allerlei Assistenten onboard und sollte damit auch zwingend eingerichtet werden. Beim einem SBS gilt "Nutze zuerst den Assistenten, danach den Assistenten und dann den Assistenten. Erst danch darfst du wenn deine Fachkenntnisse reichen selbst Hand anlegen". Ein SBS hat aber auch einschränkungen. Kein weiterer SBS in seiner Broadcastdomäne. Keine Vertrauenstellung. Nicht mehr als 75 Clients (gleichzeitig angemeldet zum nutzen von Diensten des SBS).
Man kann auch sehr viel von den Assistenten und deren Arbeit (schreiben jede menge LOG dateien mit dem was die tun) lernen.
Gruß,
Peter
Sicherheit ist immer Relativ. 100%ige Sicherheit ist nur wenn du kein Internet nutzt und keiner an den Server dran kommt Eine Firewall oder gar eine UTM vor dem netz ist immer besser als einen Server direkt ins Internet zu stellen.
Wo genau sind denn die Unterschiede? Ich benötige eigentlich nur den Exchange.
Ein Exchange gehört aber nicht auf einen DC. damit brauchst schon Zwei Server.(Ich dachte das wär einfach ein geschnürtes Paket aus Server 2008R2 und Exchange)
Ein SBS ist auch ein Server OS. Beim SBS 2011 ist es der Server 2008R2, dazu ein Exchange 2010, DNS, DHCP, Sharepoint Services, IIS, verschiedene SQL Instanzen (Monitoring, Sharepoint etc.), RWW, OWA, OMA, Outlook over HTTPS, WSUS usw. Der SQL wird auf einen Seperaten Server 2008R2 gepackt falls das SBS Addon genutzt wird.Ein SBS hat allerlei Assistenten onboard und sollte damit auch zwingend eingerichtet werden. Beim einem SBS gilt "Nutze zuerst den Assistenten, danach den Assistenten und dann den Assistenten. Erst danch darfst du wenn deine Fachkenntnisse reichen selbst Hand anlegen". Ein SBS hat aber auch einschränkungen. Kein weiterer SBS in seiner Broadcastdomäne. Keine Vertrauenstellung. Nicht mehr als 75 Clients (gleichzeitig angemeldet zum nutzen von Diensten des SBS).
Man kann auch sehr viel von den Assistenten und deren Arbeit (schreiben jede menge LOG dateien mit dem was die tun) lernen.
Gruß,
Peter
Hi.
Mit Macs aber nur in sehr alten Versionen, die sollte es eigentlich gar nicht mehr geben und bei Linux ist mir nichts bekannt.
Nein
LG Günther
Ich dachte, dass man "local" nicht wählen soll, da das immer mal wieder Problem mit Macs und Linux gibt
Mit Macs aber nur in sehr alten Versionen, die sollte es eigentlich gar nicht mehr geben und bei Linux ist mir nichts bekannt.
Kann ich SBS dazu bringen nicht mit dem Suffix "local" zu installieren bzw. kann ich das Suffix nachträglich ändern?
Nein
LG Günther