none
Problem mit Automatischen Antworten an Remote-Standort RRS feed

  • Frage

  • Hallo,

    wir haben einen Kunden mit zwei Standorten, die per Standleitung verbunden sind. Am Hauptstandort befindet sich ein SBS 2011. Dort funktionieren die Automatischen Antworten. (Mit Outlook 2013) Am Remotestandort kommt die Fehlermeldung, der Server wäre nicht verfügbar. (ihre einstellungen für automatische antworten können nicht angezeigt werden, da der server zurzeit nicht verfügbar ist.) Auf dem Terminalserver am Hauptstandort funktionieren die Automatischen Anworten auch.

    Googelt man den Fehler, bekommt man immer den Hinweis auf Autodiscover. Überprüft man das mit der Remoteverbindungsuntersuchung, schlägt das in beiden Standorten fehl. Ist auch kein Wunder, weil er versucht, eine Verbindung anhand der E-Mail-Domäne herzustellen, die sich, wie wohl bei den meisten, von der Active-Directory-Domäne unterscheidet.

    Jedenfalls denke ich nicht, dass es daran liegt. Den einzigen Unterschied, den ich im Bezug auf DNS festellen konnte ist, dass sich am Remotestandort der DNS-Name des Servers per nslookup nicht auflösen läßt. FQDN geht. Ping geht auch, wenn man voher einmal den FQDN gemacht hat. Was seltsam ist, da beide Standorte den SBS als DNS-Server hernehmen. Die Standleitung machen zwei Securepoint Firewalls. Zu denen kann ich wenig sagen, weil ich das nicht gemacht habe.

    Vielen Dank und viele Grüße,

    Hanisu

    Mittwoch, 2. September 2015 07:26

Antworten

  • Am 02.09.2015 schrieb Hanisu:
    Hi,

    wir haben einen Kunden mit zwei Standorten, die per Standleitung verbunden sind. Am Hauptstandort befindet sich ein SBS 2011. Dort funktionieren die Automatischen Antworten. (Mit Outlook 2013) Am Remotestandort kommt die Fehlermeldung, der Server wäre nicht verfügbar. (ihre einstellungen für automatische antworten können nicht angezeigt werden, da der server zurzeit nicht verfügbar ist.) Auf dem Terminalserver am Hauptstandort funktionieren die Automatischen Anworten auch.

    Googelt man den Fehler, bekommt man immer den Hinweis auf Autodiscover. Überprüft man das mit der Remoteverbindungsuntersuchung, schlägt das in beiden Standorten fehl. Ist auch kein Wunder, weil er versucht, eine Verbindung anhand der E-Mail-Domäne herzustellen, die sich, wie wohl bei den meisten, von der Active-Directory-Domäne unterscheidet.

    Du suchst eine Split-DNS Konfiguration. Damit sollte das Problem relativ schnell lösbar sein.

    Jedenfalls denke ich nicht, dass es daran liegt. Den einzigen Unterschied, den ich im Bezug auf DNS festellen konnte ist, dass sich am Remotestandort der DNS-Name des Servers per nslookup nicht auflösen läßt. FQDN geht. Ping geht auch, wenn man voher einmal den FQDN gemacht hat. Was seltsam ist, da beide Standorte den SBS als DNS-Server hernehmen. Die Standleitung machen zwei Securepoint Firewalls. Zu denen kann ich wenig sagen, weil ich das nicht gemacht habe.

    Die Frage ist immer, wie kommen deine Clients zur konfigurierten Webservices URL. Weitere Fehlerquellen sind Proxyserver und/oder Routingprobleme.

    Bye
    Norbert


    Dilbert's words of wisdom #19:
    Am I getting smart with you? How would you know?
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Mittwoch, 2. September 2015 07:57
  • > Im EWS steht unter InternalURL: https://fqdn/EWS/Exchange.asmx
    > Diese Datei wird problemlos im Browser anzeigt. Ich bekomme allerdings den Fehler, dass das Zertifikat nicht überprüft werden kann. Ist es das vielleicht?

    Es darf keinen Zertifikatsfehler geben.

    > Unter ExternalURL steht nichts. Das müsste aber in Ordnung sein?

    Wenn Du nur AD-Clients hast, muss da nichts stehen. Allerdings darf dann auch keines dieser Geräte außerhalb des Netzwerkes betrieben werden (Stichwort Notebooks).

    > Die Sache mit der E-Mail-Domäne habe ich nicht ganz verstanden. Ich ändere die InternalURL auf https://mail.emaildomäne.de/EWS/Exchange.asmx, muss dann im DNS-Server aber eine neue Zone mit der E-Mail-Domäne anlegen und mail.emaildomäne.de als Host?

    Ja, so ist das gemeint.

    Und die "ExternalURL" setzt Du auch auf diesen Wert. Ein interner Client bekommt vom internen DNS-Server eine interne IP-Adresse. Ein externer bekommt eine andere IP-Adresse für den gleichen Namen.

    > FQDN ist für mich der DNS-Name mit der Domäne dahinter.

    Was Du meinst, nennt man "Hostname".

    Hostname + Domäne = FQDN.

    > Es scheint wirklich nur mit nslookup nicht zu gehen. Ping geht, im Browser kann man auch den kurzen Namen verwenden. Das scheint nicht das Problem zu sein.

    Wichtig ist die Antwort von Ping.

    Beispiel:

    C:\>ping home-host01

    Ping wird ausgeführt für home-host01.DOMAIN.TLD [192.168.11.162] mit 32 Bytes Daten:

    Das wäre ok.

    C:\>ping home-host01

    Ping wird ausgeführt für home-host01 [192.168.11.162] mit 32 Bytes Daten:

    Das wäre falsch.

    Aber das mit dem kurzen Namen (=Hostnamen) nützt Dir ja auch nichts, weil die URL und das Zertifikat korrekterweise auf den FQDN ausgestellt sind.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 2. September 2015 17:31

Alle Antworten

  • Am 02.09.2015 schrieb Hanisu:
    Hi,

    wir haben einen Kunden mit zwei Standorten, die per Standleitung verbunden sind. Am Hauptstandort befindet sich ein SBS 2011. Dort funktionieren die Automatischen Antworten. (Mit Outlook 2013) Am Remotestandort kommt die Fehlermeldung, der Server wäre nicht verfügbar. (ihre einstellungen für automatische antworten können nicht angezeigt werden, da der server zurzeit nicht verfügbar ist.) Auf dem Terminalserver am Hauptstandort funktionieren die Automatischen Anworten auch.

    Googelt man den Fehler, bekommt man immer den Hinweis auf Autodiscover. Überprüft man das mit der Remoteverbindungsuntersuchung, schlägt das in beiden Standorten fehl. Ist auch kein Wunder, weil er versucht, eine Verbindung anhand der E-Mail-Domäne herzustellen, die sich, wie wohl bei den meisten, von der Active-Directory-Domäne unterscheidet.

    Du suchst eine Split-DNS Konfiguration. Damit sollte das Problem relativ schnell lösbar sein.

    Jedenfalls denke ich nicht, dass es daran liegt. Den einzigen Unterschied, den ich im Bezug auf DNS festellen konnte ist, dass sich am Remotestandort der DNS-Name des Servers per nslookup nicht auflösen läßt. FQDN geht. Ping geht auch, wenn man voher einmal den FQDN gemacht hat. Was seltsam ist, da beide Standorte den SBS als DNS-Server hernehmen. Die Standleitung machen zwei Securepoint Firewalls. Zu denen kann ich wenig sagen, weil ich das nicht gemacht habe.

    Die Frage ist immer, wie kommen deine Clients zur konfigurierten Webservices URL. Weitere Fehlerquellen sind Proxyserver und/oder Routingprobleme.

    Bye
    Norbert


    Dilbert's words of wisdom #19:
    Am I getting smart with you? How would you know?
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Mittwoch, 2. September 2015 07:57
  • > Googelt man den Fehler, bekommt man immer den Hinweis auf Autodiscover.

    Das ist korrekt. Nur über diesen Mechanismus bekommt die Client die URLs für die Exchange Webservices und die braucht er für den OOF.

    Und die URLs müssen korrekt sein und der Client sie ohne Zertifikatsfehler direkt aufrufen können-

    > Überprüft man das mit der Remoteverbindungsuntersuchung, schlägt das in beiden Standorten fehl.

    Das könnte ein Grund für das Nicht-Funktioneren sein. Muss aber nicht, weil es interne andere URLs als extern geben könnte.

    Soll man allerdings nicht machen, hier kommt das von Norbert erwähnte Split-DNS ins Spiel.

    > Ist auch kein Wunder, weil er versucht, eine Verbindung anhand der E-Mail-Domäne herzustellen, die sich, wie wohl bei den meisten, von der Active-Directory-Domäne unterscheidet.

    Ja, aber die URLs für EWS und die anderen Webdienste kannst Du frei konfigurieren. Und da Dich niemand daran hinter, gilt es als ziemlich clever (= Best Practise), die URLs an die Mail-Domäne anzugleichen, z.B. "mail.domain.tld".

    > Remotestandort der DNS-Name des Servers per nslookup nicht auflösen läßt. FQDN geht.

    Aus Interesse: Was ist denn bei Dir der Unterschied zwischen DNS-Name und FQDN?

    Eigentlich ist das das gleiche. Falls Du damit meinst, dass Du bei Ping den "kurzen" Namen verwendest, dann hast Du ein Problem mit den Such-Suffixen. Was innerhalb einer Domäne und bei Domänen-Rechner auf eine Fehlerkonfiguration des Clients hindeuten würde oder irgendein grundlegendes Problem hindeuten würde.

    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 2. September 2015 14:56
  • Vielen Dank!

    Im EWS steht unter InternalURL: https://fqdn/EWS/Exchange.asmx

    Diese Datei wird problemlos im Browser anzeigt. Ich bekomme allerdings den Fehler, dass das Zertifikat nicht überprüft werden kann. Ist es das vielleicht?

    Unter ExternalURL steht nichts. Das müsste aber in Ordnung sein?

    Die Sache mit der E-Mail-Domäne habe ich nicht ganz verstanden. Ich ändere die InternalURL auf https://mail.emaildomäne.de/EWS/Exchange.asmx, muss dann im DNS-Server aber eine neue Zone mit der E-Mail-Domäne anlegen und mail.emaildomäne.de als Host?

    FQDN ist für mich der DNS-Name mit der Domäne dahinter. Es scheint wirklich nur mit nslookup nicht zu gehen. Ping geht, im Browser kann man auch den kurzen Namen verwenden. Das scheint nicht das Problem zu sein.

    Viele Grüße,

    Hanisu

    Mittwoch, 2. September 2015 17:15
  • > Im EWS steht unter InternalURL: https://fqdn/EWS/Exchange.asmx
    > Diese Datei wird problemlos im Browser anzeigt. Ich bekomme allerdings den Fehler, dass das Zertifikat nicht überprüft werden kann. Ist es das vielleicht?

    Es darf keinen Zertifikatsfehler geben.

    > Unter ExternalURL steht nichts. Das müsste aber in Ordnung sein?

    Wenn Du nur AD-Clients hast, muss da nichts stehen. Allerdings darf dann auch keines dieser Geräte außerhalb des Netzwerkes betrieben werden (Stichwort Notebooks).

    > Die Sache mit der E-Mail-Domäne habe ich nicht ganz verstanden. Ich ändere die InternalURL auf https://mail.emaildomäne.de/EWS/Exchange.asmx, muss dann im DNS-Server aber eine neue Zone mit der E-Mail-Domäne anlegen und mail.emaildomäne.de als Host?

    Ja, so ist das gemeint.

    Und die "ExternalURL" setzt Du auch auf diesen Wert. Ein interner Client bekommt vom internen DNS-Server eine interne IP-Adresse. Ein externer bekommt eine andere IP-Adresse für den gleichen Namen.

    > FQDN ist für mich der DNS-Name mit der Domäne dahinter.

    Was Du meinst, nennt man "Hostname".

    Hostname + Domäne = FQDN.

    > Es scheint wirklich nur mit nslookup nicht zu gehen. Ping geht, im Browser kann man auch den kurzen Namen verwenden. Das scheint nicht das Problem zu sein.

    Wichtig ist die Antwort von Ping.

    Beispiel:

    C:\>ping home-host01

    Ping wird ausgeführt für home-host01.DOMAIN.TLD [192.168.11.162] mit 32 Bytes Daten:

    Das wäre ok.

    C:\>ping home-host01

    Ping wird ausgeführt für home-host01 [192.168.11.162] mit 32 Bytes Daten:

    Das wäre falsch.

    Aber das mit dem kurzen Namen (=Hostnamen) nützt Dir ja auch nichts, weil die URL und das Zertifikat korrekterweise auf den FQDN ausgestellt sind.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 2. September 2015 17:31
  • Am 02.09.2015 schrieb Hanisu:
    Hi,
     > Im EWS steht unter InternalURL: https://fqdn/EWS/Exchange.asmx


    Diese Datei wird problemlos im Browser anzeigt. Ich bekomme allerdings den Fehler, dass das Zertifikat nicht überprüft werden kann. Ist es das vielleicht?

    Ja das ist es mit Sicherheit. Outlook hat nunmal keine GUI um den Zertifikatsfehler zu ignorieren, also bekommst du keine ANzeige.

    Unter ExternalURL steht nichts. Das müsste aber in Ordnung sein?

    Ich habe den "Verdacht", dass dein Server/SBS irgendwie konfiguriert wurde. Normalerweise sollte ja alles auf remote.domainname.tld konfiguriert worden sein. Sowohl von innen als auch von aussen. Und demzufolge sollte im Zertifikat auch dieser Name drin stehen.

    Die Sache mit der E-Mail-Domäne habe ich nicht ganz verstanden. Ich ändere die InternalURL auf https://mail.emaildomäne.de/EWS/Exchange.asmx, muss dann im DNS-Server aber eine neue Zone mit der E-Mail-Domäne anlegen und mail.emaildomäne.de als Host?

    Bitte nicht einfach was ändern, von dem du die Auswirkungen nicht abschätzen kannst.

    FQDN ist für mich der DNS-Name mit der Domäne dahinter.

    Ja FQHN nutzt ja kaum jemand, sondern meint mit FQDN normalerweise host mit Domain hinten dran. ;)

    Es scheint wirklich nur mit nslookup nicht zu gehen. Ping geht, im Browser kann man auch den kurzen Namen verwenden. Das scheint nicht das Problem zu sein.

    Der kurze Name interessiert aber niemanden. ;)

    Bye
    Norbert


    Dilbert's words of wisdom #04:
    There are very few personal problems that cannot be solved by a suitable application of high explosives.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Mittwoch, 2. September 2015 17:32
  • Hallo,

    im Internet Explorer des Terminalservers ist tatsächlich das Zertifikat der CA des Exchangeservers vorhanden, welches in meinem IE gefehlt hat. Also habe ich es importiert. Der Zertifikatfehler kommt jetzt beim Aufruf über den Browser nicht mehr. Die Automatischen Anworten gehen aber noch immer nicht. Noch irgendwelche Ideen?

    Freitag, 4. September 2015 10:02