none
Fehlersuche beim ExchangeConnectivity-Test ... RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Ich versuche einem Problem bei der Anmeldung eines MacBook bei Exchange auf die Schliche zu kommen.

    Dabei bin ich auf den Remote Connectivity Analyzer gestossen, der jetzt bei einem der Tests einen Fehler ausgibt:

    Exchange-Webdienste: Synchronisierung, Benachrichtigung, Verfügbarkeit und automatische Antworten.

    Der Fehler:

    Es wird ein temporärer Ordner zur Ausführung von Synchronisierungstests erstellt.
 	Fehler beim Erstellen des temporären Ordners zur Durchführung von Tests.
 	
	Weitere Details
 	
Ausnahmedetails:
Nachricht: The request failed. The remote name could not be resolved: 'exchange.interne.domain'

    Das Problem scheint darin zu liegen, daß versucht wird, einen temporären Ordner anzulegen und dabei der INTERNE Name des Exchange-Servers verwendet wird.

    Die im Test verwendete Mail-Adresse lautet <benutzer>@betonklotz.cc.

    Andere Tests haben bereits Erfolg gehabt (allerdings immer mit der EInstelleung "SSL Vertrauensstellung ignorieren", da das zertifikat ein selbst verstelltes ist.

    Kann mir jemand helfen ?

    Montag, 13. Januar 2014 10:01
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Jetzt kann ich mir mal selber eine Antwort geben:

    Mittleweile scheint es zu funktionieren.

    Die Lösung:

    - Outlook ANywhere wieder deaktiveren am Exchange

    - RPC-over-HTTP Feature de-installieren

    - Neustart

    -RPC-Feature wieder neu installieren

    -Neustart

    - Outlook Anywhere erenut aktivieren

    • Als Antwort markiert Alex Pitulice Dienstag, 4. März 2014 11:38
    Dienstag, 4. März 2014 05:43
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden
    Hallo. Also was ich aus der Meldung sehe ist, dass er den Server im DNS nicht auflösen kann. Kannst du mit nslookup den exchange.interne.domain auflösen ?
    Montag, 13. Januar 2014 10:28
    |
  • Question
    Anmelden
    0
    Anmelden

    Schon richtig.

    Eigentlich wundert es mich nicht, daß <daß der interne Name des Exchange-Servers nicht aufgelöst werden kann.

    Wenn ich den Test von irgendwoher ausführe ist das ja nicht verwunderlich.

    Der externe Name wird auf jeden Fall aufgelöst.

    Oder muss der Exchange-Server seinen eigenen Namen auflösen können?

    Montag, 13. Januar 2014 10:38
    |
  • Question
    Anmelden
    0
    Anmelden

    Zusätzlich, hast du die EWS URLs auf für extern gesetzt?

    Gruß

    Jörg

    Montag, 13. Januar 2014 10:40
    |
  • Question
    Anmelden
    0
    Anmelden
    Yippie ! Was bitte heisst das ? Wo muss ich das konfigurieren ?
    Montag, 13. Januar 2014 10:43
    |
  • Question
    Anmelden
    0
    Anmelden

    Get-WebServicesVirtualDirectory <dein servername>\ews* | fl *url*

    da sollte dann ein ähnliches Ergebnis erscheinen.

    InternalUrl          : https://exchange.intern.domain/EWS/Exchange.asmx
    ExternalUrl          : https://exchange.extern.domain/EWS/Exchange.asmx

    Falls nicht mußt du mit Set-WebServicesVirtualDirectory die External URL setzen.

    Gruß

    Jörg

    Montag, 13. Januar 2014 11:20
    |
  • Question
    Anmelden
    0
    Anmelden

    InternalNLBBypassUrl : https://<int_name>.<intern>.<domäne>/ews/exchange.asmx
    InternalUrl          : https://<int_name>.<intern>.<domäne>/EWS/Exchange.asmx
    ExternalUrl          : https://webmail.<externe>.<doamäne>/EWS/Exchange.asmx

    SO, das ist das Ergebnis von Get-WebServices. Als Namen habe ich den INTERNEN Namen des Exchange verwendet.

    Sieht doch eigentlich ganz attraktiv aus, oder ? 

    2 Dinge:

    - der in der Fehlermeldung (s.o.) bemängelte Name entspricht dem aus InternalUrl und InternalBypassUrl

    - sowohl der FQDN intern als auch der externe FQDN (also webmail.xxx.yy) sind im Zertifikat als alternativer Antragstellername vertreten.

    Ich würde also jetzt keine Notwendigkeit sehen, irgendwas zu ändern

    Montag, 13. Januar 2014 12:56
    |
  • Question
    Anmelden
    0
    Anmelden

    InternalNLBBypassUrl : https://<int_name>.<intern>.<domäne>/ews/exchange.asmx
    InternalUrl          : https://<int_name>.<intern>.<domäne>/EWS/Exchange.asmx
    ExternalUrl          : https://webmail.<externe>.<doamäne>/EWS/Exchange.asmx

    SO, das ist das Ergebnis von Get-WebServices. Als Namen habe ich den INTERNEN Namen des Exchange verwendet.

    Sieht doch eigentlich ganz attraktiv aus, oder ? 

    2 Dinge:

    - der in der Fehlermeldung (s.o.) bemängelte Name entspricht dem aus InternalUrl und InternalBypassUrl

    - sowohl der FQDN intern als auch der externe FQDN (also webmail.xxx.yy) sind im Zertifikat als alternativer Antragstellername vertreten.

    Ich würde also jetzt keine Notwendigkeit sehen, irgendwas zu ändern

    Jo das sieht soweit gut aus.
    Montag, 13. Januar 2014 13:02
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi NicoNi,

    kannst du noch etwas über deine Umgebung schreiben. Habt ihr noch einen TMG dazwischen und um was für einen Exchange handelt es sich genau?

    Viele Grüße
    Christian

    Montag, 13. Januar 2014 18:54
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Es handelt sich um einen Exhcange 2007, der hinter einer NAT (Router) steht.

    Donnerstag, 16. Januar 2014 19:28
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi NicoNi,

    bist du schon weiter? Sind bei Exchange und Outlook alle Updates installiert? Internt glaubt es und kannst du die Rückgabe des Outlook Email-Autokonfigtest mal posten.

    Hier gab es auch mal einen langen Thread ... leider ohne Lösung.
    http://social.technet.microsoft.com/Forums/exchange/en-US/59bf9a88-7368-4ee5-bf40-24a6e72c1fa4/autodiscover-providing-wrong-url-domain?forum=exchangesvrgenerallegacy

    Viele Grüße
    Christian

    Freitag, 17. Januar 2014 18:08
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Nein, ich bin nicht weitergekommen.

    Das aktuelle Problem ist beim Versuch einen MacBook an ein Exchange-Konto zu binden entstanden - das funktioniert nicht.

    Umso lustiger: Ein iPhone kann völlig ohne Probleme auf das Exchange-Konto zugreifen, genauso mein eigenes S3 und mein Windows-PC.

    Nur der verdammte MacBook zickt! (Outlook.mac 2011)

    Samstag, 18. Januar 2014 16:45
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo NicoNi,

    hast Du in der Zwischenzeit die Ursache des Problems vielleicht gefunden?

    Gruss,

    Alex

    Alex Pitulice, MICROSOFT 
    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Montag, 3. Februar 2014 11:55
    |
  • Question
    Anmelden
    0
    Anmelden

    die Telefone machen das über owa. Outlook richtig über Exchange.

    dein pc ist wohl in der Domäne und der mac nicht?

    Montag, 3. Februar 2014 12:15
    |
  • Question
    Anmelden
    0
    Anmelden

    Nein, leider nicht.

    Zwischenzeitlich glaube ich das Problem mit dem Mac/Outlook/Exchange im Griff zu haben, daß funktioniert aber nur temporär.

    Montag, 3. Februar 2014 12:26
    |
  • Question
    Anmelden
    0
    Anmelden

    Ich kämpfe noch immer mit dem Zugriff auf Outlook/Exchange.

    DIe Geschichte mit dem Mac hatte ich ad acta gelegt.

    BTW: der Mac ist nicht in der Domäne.

    Jetzt kocht die Geschichte aber wieder hoch  diesmal im Zusammenhang mit Outlook-Anywhere. Ich schätze, daß ganze hat letztlich dieselbe Ursache  wie bei dem Mac.

    TestExchangeconnectivity scheitert bei der Prüfung von/für Outlook Anywhere.

    Ich habe schon herausgefunden, daß unbedingt ein gültiges Zertifikat benötigt wird.

    Auffällig ist auch, daß man bei den anderen Testen die Gültigkeit des SSL-Zertifikates ignorieren konnte, nicht aber bei dem Outlook Anywhere-Test.

    Die folgenden Meldungen bekomme ich:

    Zertifikatsvertrauensstellung wird überprüft.
      Fehler bei der Überprüfung der Vertrauenswürdigkeit des Zertifikats.
     
    Testschritte
     
    Die Microsoft-Verbindungsuntersuchung versucht, Zertifikatketten für Zertifikat CN=<domname>, CN=<extfqdn>, O=Gutachtenbüro, C=DE zu erstellen.
      Für das Zertifikat konnte keine Zertifikatkette erstellt werden.
     
    Weitere Details
     
    Die Zertifikatkette konnte nicht erstellt werden. Möglicherweise fehlen erforderliche Zwischenzertifikate.
    Verstrichene Zeit: 37 ms.
      Fehler bei der Überprüfung der Vertrauenswürdigkeit des Zertifikats.

    Die EInrückungen kriege ich leider nicht weg.

    Das ganze irritiert, da auf dem Rechner, von dem aus testexchangeconnectivity aufgerufen wurde, die Zertifikate, inkl Zwischenzertfifikat installiert sind (sein solten).

    Ich kann mich auf https://extfqdn/rpc verbinden, die Credentials werden abgefragt und gut is.

    Keine Warnung, nix.

    Wenn ich die Zertifikate anschaue, dann sind das Zertifikat der Webseite und das übergeordnete jeweils als gültig markiert.

    Ich habe diese Zertifikate auch im Speicher des Rechners.

    Was kann ich denn noch tun ?


     
    Samstag, 1. März 2014 15:16
    |
  • Question
    Anmelden
    1
    Anmelden

    Jetzt kann ich mir mal selber eine Antwort geben:

    Mittleweile scheint es zu funktionieren.

    Die Lösung:

    - Outlook ANywhere wieder deaktiveren am Exchange

    - RPC-over-HTTP Feature de-installieren

    - Neustart

    -RPC-Feature wieder neu installieren

    -Neustart

    - Outlook Anywhere erenut aktivieren

    • Als Antwort markiert Alex Pitulice Dienstag, 4. März 2014 11:38
    Dienstag, 4. März 2014 05:43
    |