none
Problem mit Test-ActiveSyncConnectivity RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo!


    Seit kurzem funktioniert das ActiveSyncConnectivity Test cmdlet bei uns in der 2013 Umgebung nicht mehr so wie gewünscht und unser Monitoringtool beklagt sich darüber.

    Umgebung besteht aus 2 CAS Servern und 3 Mailboxservern in einer DAG. Die CAS und MBX befinden sich in 2 verschiedenen IP-Adresskreisen über eine Firewall geroutet, derzeit keine Einschränkungen auf dem Paketfilter. Der interne Domänenname entspricht dem externen, Servernamen gibts nur intern.


    Ein Test-ActiveSyncConnectivity meldet folgendes zurück:

    Result                      : Fehler
    Error                       : Der Befehl OPTIONS hat HTTP 200 zurückgegeben, aber die Exchange ActiveSync-Kopfzeile
                                  (MS-Server-ActiveSync) wurde nicht zurückgegeben. Die Anforderung hat wahrscheinlich
                                  keinen Clientzugriffsserver erreicht. Mögliche Ursachen

                                   - Ein Proxyserver hat eingegriffen (prüfen Sie die folgenden Kopfzeilen auf mögliche
                                  Daten, die von einem Proxy zurückgegeben worden sein könnten)

                                   - Das virtuelle Verzeichnis war nicht erreichbar:
                                  https://mbx1.domain.net/Microsoft-Server-ActiveSync

                                   - Das virtuelle Verzeichnis verweist nicht auf einen Clientzugriffsserver:
                                  https://mbx1.domain.net/Microsoft-Server-ActiveSync.

                                  HTTP-Antwortkopfzeilen:

                                  Allow: OPTIONS, TRACE, GET, HEAD, POST
                                  Public: OPTIONS, TRACE, GET, HEAD, POST
                                  Content-Length: 0
                                  Date: Fri, 03 Jul 2015 11:40:13 GMT
                                  Server: Microsoft-IIS/8.5
                                  X-Powered-By: ASP.NET


    Die eingerichtete externe URL auf den ActiveSync virtual Directorys lautet auf die NLB Adresse der CAS: https://nlb.domain.net/Microsoft-Server-ActiveSync

    Gebe ich den Befehl Test-ActiveSyncConnectivity mit dem Parameter -URL https://nlb.domain.net/Microsoft-Server-ActiveSync an, dann funktioniert dies! Was kann die Ursache dafür sein, daß der Befehl ohne Parameter nicht mehr funktioniert?!

    Außerdem bin ich noch über folgendes gestolpert:

    Test-EcpConnectivity

    ClientAccessServer          : mbx1.domain.net
    Scenario                    : Anmeldung
    ScenarioDescription         : Melden Sie sich bei Exchange-Systemsteuerung an, und überprüfen Sie die Antwortseit
    PerformanceCounterName      :
    Result                      : Ausgelassen
    Error                       : Die interne URL des virtuellen Verzeichnisses konnte durch den Test nicht geprüft
                                  werden. Dies liegt daran, dass die InternalURL-Eigenschaft nicht festgelegt wurde.


    Die interne URL ist auf dem Ecp Verzeichnis der CAS korrekt konfiguriert. Wie soll ich sie für den/die Mailboxserver festlegen!?

    Wäre spitze wenn mir jemand den Schubs in die richtige Richtung gibt, ich hab mir schon einen Wolf abgesucht nach der Ursache :-(

    Grüße
    Susanne

    Freitag, 3. Juli 2015 12:53
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Moin,

    ganz ehrlich: Dein Konstrukt ist so kompliziert und so weit weg vom Best-Practise - dass muss sich jemand bei Dir vor Ort ansehen.

    Da gibt es so viele potentielle Fehlerquellen auch Abseits von Exchange, das wir in einem Forum da kaum einen sinnvollen Überblick bekommen können. (ich hatte mal einen Kunden mit einem ähnlichen Aufbau und ganz großen Problem beim Fail-Over und nur am Rande fiel auf, dass ein Standard-Gateway verkehrt gesetzt war; 5 Stunden Fehlersuche in Exchange gelöst in 10 Sekunden).

    Das beginnt ja schon mit Deinem einleitenden Satz: "Bis vor kurzem".... Also muss ja irgendwas geändert worden sein und Du musst zuerst mal herausfinden, was geändert wurde.

    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Freitag, 3. Juli 2015 14:18
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Susanne,

    meine Standardantwort auf die Standardantwort lautet: Irgendwas muss sich geändert haben, sonst würde es noch laufen. ;)

    Die Schwierigkeit ist nur, herauszufinden, was geändert wurde.

    Zum Best-Practise und den Besonderheiten bei Deiner Umgebung:

     - spätestens ab 2013 (eigentlich schon mit 2010) wird Multi-Role empfohlen; dedizierte CAS-Server bringen bei 2013 wenig (weshalb sie bei 2016 wieder abgeschafft werden), erhöhen aber die Komplexität und Wartung erheblich; ein CAS-Array gibt es bei 2013 gar nicht mehr

     - eine DAG über zwei IP-Netze ist aufwendig und nicht mit Standard-Einstellungen (sprich "ich packe einfach mal zwei Server in getrennte Räume") erlaubt; "Data Center Resiliency" ist aufwendig und muss besonders konfiguriert werden

     - eine Firewall zwischen Exchange ist zwar nicht verboten, es wird aber dringend davon abgeraten; grundsätzlich wird erwartet, dass diese die Exchange und die DC jeden mit jeden ohne jegliche Filterung verbindet - Any : Any. Also quasi wie ohne Firewall;

     - ein Domänen-Name, der intern und extern gleich heißt (ich nehme an, Du beziehst Du darauf, dass Dein AD wie Deine Mail-Domäne heißt), ist zwar möglich, aber wieder sehr aufwendig und fehlerträchtig in Bezug auf  DNS und AD -> und Fehler in DNS/AD sind gleichzeitig auch Probleme in Exchange

     - im Gegensatz zum vorgenannten Punkt hast Du aber scheinbar kein empfohlenes Split DNS; ohne Split DNS wird die Umgebung in Bezug auf wieder komplizierter;

    Reicht das, um zu begründen, warum Deine Umgebung ziemlich außergewöhnlich ist? Ich würde mal sagen, dass ich in mehr als 10 Jahren mit Exchange-Kunden so viele Besonderheit vielleicht ein- oder zweimal gesehen habe. Nicht falschverstehen: Das heißt nicht, dass es nicht möglich ist. Es heißt nur, dass man sehr genau wissen muss, was und warum man das macht.

    Bei Exchange gilt "Keep it simple".

    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Freitag, 3. Juli 2015 19:21
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Moin,

    ganz ehrlich: Dein Konstrukt ist so kompliziert und so weit weg vom Best-Practise - dass muss sich jemand bei Dir vor Ort ansehen.

    Da gibt es so viele potentielle Fehlerquellen auch Abseits von Exchange, das wir in einem Forum da kaum einen sinnvollen Überblick bekommen können. (ich hatte mal einen Kunden mit einem ähnlichen Aufbau und ganz großen Problem beim Fail-Over und nur am Rande fiel auf, dass ein Standard-Gateway verkehrt gesetzt war; 5 Stunden Fehlersuche in Exchange gelöst in 10 Sekunden).

    Das beginnt ja schon mit Deinem einleitenden Satz: "Bis vor kurzem".... Also muss ja irgendwas geändert worden sein und Du musst zuerst mal herausfinden, was geändert wurde.

    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Freitag, 3. Juli 2015 14:18
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo!

    Geändert wurde nichts (ja, ich weiß - Standardantwort).

    Das einzige was mir da markant in Erinnerung ist, ist das die Festplatten der Mailboxserver vollliefen. Habs gleich bemerkt und behoben (virtualisierte Umgebung) und Fehler lassen sich keine mehr in den Eventlogs finden.

    Hätte nun nicht gedacht, daß die Konfiguration so unüblich ist. 1 Cas-Array mit einer DAG hintendran findet sich häufiger und ich hab die Konfiguration entsprechend vielzähliger gleichlautender Anleitungen durchgeführt.

    Aber danke für deine Antwort.

    Grüße

    Susanne

    Freitag, 3. Juli 2015 14:56
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Susanne,

    meine Standardantwort auf die Standardantwort lautet: Irgendwas muss sich geändert haben, sonst würde es noch laufen. ;)

    Die Schwierigkeit ist nur, herauszufinden, was geändert wurde.

    Zum Best-Practise und den Besonderheiten bei Deiner Umgebung:

     - spätestens ab 2013 (eigentlich schon mit 2010) wird Multi-Role empfohlen; dedizierte CAS-Server bringen bei 2013 wenig (weshalb sie bei 2016 wieder abgeschafft werden), erhöhen aber die Komplexität und Wartung erheblich; ein CAS-Array gibt es bei 2013 gar nicht mehr

     - eine DAG über zwei IP-Netze ist aufwendig und nicht mit Standard-Einstellungen (sprich "ich packe einfach mal zwei Server in getrennte Räume") erlaubt; "Data Center Resiliency" ist aufwendig und muss besonders konfiguriert werden

     - eine Firewall zwischen Exchange ist zwar nicht verboten, es wird aber dringend davon abgeraten; grundsätzlich wird erwartet, dass diese die Exchange und die DC jeden mit jeden ohne jegliche Filterung verbindet - Any : Any. Also quasi wie ohne Firewall;

     - ein Domänen-Name, der intern und extern gleich heißt (ich nehme an, Du beziehst Du darauf, dass Dein AD wie Deine Mail-Domäne heißt), ist zwar möglich, aber wieder sehr aufwendig und fehlerträchtig in Bezug auf  DNS und AD -> und Fehler in DNS/AD sind gleichzeitig auch Probleme in Exchange

     - im Gegensatz zum vorgenannten Punkt hast Du aber scheinbar kein empfohlenes Split DNS; ohne Split DNS wird die Umgebung in Bezug auf wieder komplizierter;

    Reicht das, um zu begründen, warum Deine Umgebung ziemlich außergewöhnlich ist? Ich würde mal sagen, dass ich in mehr als 10 Jahren mit Exchange-Kunden so viele Besonderheit vielleicht ein- oder zweimal gesehen habe. Nicht falschverstehen: Das heißt nicht, dass es nicht möglich ist. Es heißt nur, dass man sehr genau wissen muss, was und warum man das macht.

    Bei Exchange gilt "Keep it simple".

    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Freitag, 3. Juli 2015 19:21
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Robert,

    was sich geändert hat, weiß ich zwischenzeitlich: hatte wg. entsprechender Aufforderung in einem Event einen Extestuser erstellt, den gabs vermutlich vorher nicht, drum hat das Monitoringtool nicht gemeckert. Erklärt aber natürlich nicht, warum der Test nicht geht, zumal es keinerlei Funktionseinschränkungen gibt.

    Eine SplitDNSkonfiguration liegt vor.

    Das mit dem CasArray war mir bekannt - ein Fehler meinerseits dieses Konstrukt so zu benennen.

    Das mit der Multi-Role-Empfehlung wusste ich nicht, vielen Dank für den Hinweis, da werde ich mir mal noch Infos zu sammeln.

    Grüße

    Susanne

    Freitag, 3. Juli 2015 21:27
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Susanne,

    Test-ActiveSyncConnectivity braucht eigentlich schon immer einen User - bei mir ist das "extest_40d5c32fc4674" (ich weiß aus dem Kopf gerade nicht, ob das immer der gleiche Name ist).

    Das ist bei allen CMDLETs so, die irgendwas gegen eine Mailbox prüfen und war auch schon bei 2010 so.

    Wenn bei Dir SplitDNS vorliegt, wundert es mich, dass Du oben Fehlermeldungen mit internen Adressen bekommst.

    Wie wird denn aktuell das CMDLET bei Dir aufgerufen? Es gibt mehrere Varianten, auf den lokalen Server, auf eine URL, mit Autodiscover.

    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Samstag, 4. Juli 2015 07:32
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Robert,

    der kryptische Teil hinterm extest_ entspricht den ersten Zeichen der GUID deines AD-Standortes. Natürlich ist mir bekannt, daß er nötig ist für die testcmdlets. Er existierte eben vorher vermutlich noch nicht. Aufrufen tu ich über die Exchangeshell per Befehleseingabe Test-Activesyncconnectivity von Server mit installierter Mailbox-, CAS-, oder installierten Verwaltungstools.

    Grüße

    Susanne


    Freitag, 10. Juli 2015 19:00
    |