Exchange 2007 Debugging

Die Installation der Exchange 2007 Unified Messaging Rolle ist denkbar einfach. Setup aufrufen und die Rolle mit installieren. Allerdings sollte der Server schon genug Hauptspeicher mitbringen. Allerdings benötigen Sie natürlich noch die ein oder andere Komponente.

Trotzdem kann es an der ein oder anderen Stelle einmal zwicken. Hier hilft ihnen dann die Diagnosefunktion, die Unified Messaging mitbringt. Hier ein paar Fehler, ihr Erscheinungsbild und Abhilfe:

Unified Messaging Troubleshooting Tool

Passend zu Exchange 2010 SP1 gibt es auch ein passendes Tool

Unified Messaging Troubleshooting Tool
http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=10d2e48f-0846-40b6-b08f-d282309811a2

Eine Beschreibung/Tests stehen noch aus

Fehlerfreier Start

Ob die UM-Rolle korrekt gestartet wurde, erkennen Sie am einfachsten im Eventlog:

Event Type: Information
Event Source: MSExchange Unified Messaging
Event Category: UMService 
Event ID: 1037
User: N/A
Computer: NAWSV002

Description: The Microsoft Exchange Unified Messaging service has started successfully.

Ping... oder lebst du noch ?

Exchange 2007 meldet sich alle 120 Sekunden beim UM-Gateway, um seine Bereitschaft zu signalisieren. Zusätzlich sendet es aber auch einen "PING" an das Gateway an. Ein ICMP-Paket ist sehr viel "billiger" als ein TCP-Handshake. Wenn schon ein PING nicht ankommt, dann braucht der Server TCP gar nicht erst zu versuchen. Das gleiche Verfahren nutzen auch PCs, die die Erreichbarkeit eines Domaincontrollers müssen wollen. Es ist daher eine schlechte Idee, ICMP in einem Netzwerk zu blockieren.

 

Event Type: Warning
Event Source: MSExchange Unified Messaging
Event Category: UMService 
Event ID: 1088
User: N/A
Computer: NAWSV002

Description: The IP gateway or IP-PBX did not respond to a PING request from the Unified Messaging server. The error code that was returned is "0" and the error text is 
":unable to establish a connection.".

PING ok

Wenn Sie also keine Fehler in ihrem Netzwerk haben oder temporäre Unterbrechungen, dann sollte regelmäßig ein "PING" vom Gateway auch beantwortet werden. Vorsicht bei Gateways, die z.B.: auf Windows oder Unix laufen und über integrierte Firewall verfügen. Firewalls sehen solche PING-Pakete oftmals als "Einbruch" an.

Event Type: Warning
Event Source: MSExchange Unified Messaging
Event Category: UMCore 
Event ID: 1021
User: N/A
Computer: NAWSV002

Description: The Unified Messaging server rejected an incoming call with the ID 
"sip_isdn-72-1184940405". Reason: "The Unified Messaging server cannot find a 
valid UM hunt group für "613" associated with UM IP gateway "192.168.100.140".

Keine Huntgroup

Dann sollte eigentlich schon alles soweit sein, dass sich Exchange 2007 erfolgreich am VoIP-Gateway angemeldet hat. Der nächste Fehler kann nun passieren, wenn ein eingehender Call an Exchange signalisiert wird. Wenn die Konfiguration nicht passt, dann findet sich auch hier eine Meldung im Eventlog: 

Event Type: Warning
Event Source: MSExchange Unified Messaging
Event Category: UMCore 
Event ID: 1021
User: N/A
Computer: NAWSV002

Description: The Unified Messaging server rejected an incoming call with the ID 
"sip_isdn-72-1184940405". Reason: "The Unified Messaging server cannot find a 
valid UM hunt group für "613" associated with UM IP gateway "192.168.100.140".

In diesem Fall habe ich meine Nummer 613 angerufen, welche auf die Nebenstelle 693 (Exchange 2007 UM) weiter geleitet war. Ich musste neben dem UM-Gateway (Hier eine Office Master Box von Ferrari) auch noch eine Huntgroup einrichten, die die Durchwahl 693 auf den Nummernplan "NAW Dialplan1" verbunden hat.

Event Type: Information
Event Source: MSExchange Unified Messaging
Event Category: UMManagement 
Event ID: 1062
User: N/A
Computer: NAWSV002

Description: A new Unified Messaging hunt group named "CN=Hunt 693,CN=OfficeMaster,CN=UM 
IPGateway Container,CN=Net at Work GmbH,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=netatwork,DC=de" 
has been created with pilot identifier "693" and is associated with UM dial plan 
"NAW Dialplan1".

Und beim Benutzer muss ich dann entsprechend bei der Konfiguration meiner "Durchwahl" den passenden Dialplan auswählen. 

ISDN-Probleme

Gut dran ist natürlich, wer eine ISDN-Telefonanlage hat, welche ein D-Kanal-Protokoll aktivieren kann. Dies ist zumindest dann erforderlich, wenn die TK-Anlage nicht direkt per Ethernet und TCP/IP mit dem Exchange Server sprechen kann, sondern nur eine interne ISDN-Schnittstelle für ein Gateway bereit stellt. Hier kann man dann schön die Datenpakete zwischen TK-Anlage und Gateway sehen:

Hier sieht man einen Verbindungsaufbau von der 613 (Calling party number) zur 693 (Called party number)

SIP Direktanwahl

Hier ruft dann die Durchwahl 615 die Rufnummer 693 direkt an.

 SIP Redirect

Ethernet schnüffeln

Wenn man dann noch auf dem Ethernet die Verbindung zwischen TK-Anlage/Gateway und Exchange 2007 Server mitschneidet, dann findet man dort nicht nur die regelmäßigen PING-Pakete, sondern auch die Anmeldung und die Signalisierung des eingehenden Anrufs. Hier erst mal ein Auszug bei "Ruhe":

Ethernet eingehender Ruf

Mit dem UM Testphone kann man recht einfach einen "Ruf" auf einen UM Server auslösen. Hier die Einstellungen im UM Testphone, um den Server "nawsv002" auf der Rufnummer "680" anzurufen. Exchange "sieht" dann einen eigehenden Ruf von der Rufnummer 111 und bekommt zudem mitgeteilt, dass der Ruf von der Nebenstelle 613 weitergeleitet wurde.

uM Testphone

Gibt es also einen Benutzer mit der Nebenstelle 613, dann landet der Anrufer direkt im Menü um eine Nachricht an diesen Empfänger zu hinterlassen. Lassen Sie hingegen die "Diversion" weg, dann landet der Anruf im Menü zur Auswahl der Nebenstelle.

Im NETMON kann man dann den Verbindungsaufbau wunderbar mitschneiden:

- SIP: Request: INVITE sip:680@nawsv002.netatwork.de:5060 SIP/2.0
  + RequestLine: INVITE sip:680@nawsv002.netatwork.de:5060 SIP/2.0
    FROM: <sip:111@NAWWSFC1.netatwork.de>;epid=85-BA-0E-BB-5B;tag=2b91c35f6f
    TO: <sip:680@nawsv002.netatwork.de:5060>
    CSEQ: 3 INVITE
    CallID: 44b3a691-85a0-4feb-a315-5b6b0c3aee5f
    MAX-FORWARDS: 70
    VIA: SIP/2.0/TCP 192.168.100.75:9379;branch=z9hG4bK561f2a77
    CONTACT: <sip:NAWWSFC1.netatwork.de;transport=Tcp;maddr=192.168.100.75>;proxy=replace
    CONTENT-LENGTH: 298 User-AGENT: RTCC/2.0.6017.0 (Unified Messaging Test Client)
    ContentType: application/sdp
    Diversion: <tel:613> ;reason=no-answer
    Ms-Conversation:

Man sieht hier sehr gut bei "To:" die angerufene SIP-Nebenstelle, unter der der Exchange 2007 Server gerade "lauscht". Und als "FROM" sieht man die Rufnummer 111. Für eine direkte Durchleitung auf die Mailbox ist aber das Feld "Diversion:" wichtig, da Exchange anhand dieses Felds die Mailbox findet. Hier wurde anscheinend die Durchwahl 613 angerufen, auf der aber keine Rufannahme erfolgt ist. Der Ruf wurde also sofort oder verzögert auf die Voicebox von Exchange weiter geleitet. Und einige Sekunden später landet dann auch eine entsprechende Meldung im Postfach

Die eigene Nachrichtenklasse sorgt dafür, dass Outlook ein passendes Formular öffnen kann.

Startet man den ganzen Anruf einmal "ohne "Diversion, dann kann Exchange den Ruf natürlich nicht direkt dem richtigen Postfach zuordnen und muss über eine Sprachansage den Anrufer auffordern, die Nebenstelle anzugeben. Mit Netmon erkennt man hier dann das Fehlen der Diversion

- SIP: Request: INVITE sip:680@nawsv002.netatwork.de:5060 SIP/2.0
  + RequestLine: INVITE sip:680@nawsv002.netatwork.de:5060 SIP/2.0
    FROM: <sip:111@NAWWSFC1.netatwork.de>;epid=FE-58-C7-E8-A8;tag=71f9eba3f5
    TO: <sip:680@nawsv002.netatwork.de:5060>
    CSEQ: 1 INVITE
    CallID: 21d8f661-8661-4bf6-b70e-568292103662
    MAX-FORWARDS: 70
    VIA: SIP/2.0/TCP 192.168.100.75:9467;branch=z9hG4bKd7eb3411
    CONTACT: <sip:NAWWSFC1.netatwork.de;transport=Tcp;maddr=192.168.100.75>;proxy=replace
    CONTENT-LENGTH: 298 User-AGENT: RTCC/2.0.6017.0 (Unified Messaging Test Client)
    ContentType: application/sdp
    Ms-Conversation-ID: 0fcd7cb0-d1de-4aa8-81eb-e201847b733

Verbindung zu Exchange

Eingehende Sprachnachrichten werden von der UM-Rolle zuerst in einem lokalen Verzeichnis temporär gespeichert und dann über SMTP an einen HubTransport in der gleichen AD-Site zugestellt. Die UM-Rolle versucht dabei nacheinander die verschiedenen HTs zu erreichen, bis die Zustellung erfolgreich ist. Ist kein HT erreichbar, wird die Zustellung einfach später versucht. Fehler landen im Eventlog aber sie könnten dennoch auch das Verzeichnis mit anderen Tools überwachen.

Damit die Zustellung erfolgreich ist, müssen mehrere Faktoren zutreffen:

  • HubTransport auffindbar und auflösbar
    Die UM-Rolle nutzt die Exchange Konfiguration und die AD-Sites, um eine Liste der Hub-Transport-Server in der lokalen AD-Site zu erstellen und dann per DNS die IP-Adresse zu den Servern aufzulösen. Das muss natürlich funktionieren. Ein "ipconfig /displaydns" auf dem Server mit der UM-Rolle zeigt ihnen recht einfach, welche Hostnamen und Adressen der Server aufgelöst hat.
  • HubTransport per Port 25 erreichbar
    Die UM-Rolle sendet die Mails per SMTP an den Transport. Diese Verbindung muss möglich sein, und es gibt gleich mehrere Hindernisse. Eine Netzwerkfirewall oder auch der ein oder andere voreilige Virenscanner lokaler Virenscanner, Netzwerkfirewall
  • "vertrauenswürdiges" Zertifikate (Nicht selbst signiert)
    Die Exchange UM-Rolle verbindet sich per SMTP und nutzt TLS zur Verschlüsselung. Es ist erforderlich, dass der HubTransport daher ein passendes Zertifikat hat, welches von dem UM-Server als "vertrauenswürdig" angesehen wird. Das per Default auf einer HubTransport-Rolle installierte Selbstzertifikat ist NICHT geeignet, da die UM-Rolle diesem nicht vertraut. Es muss also schon ein Zertifikat einer den Clients als vertrauenswürdig angesehenen CA sein. Dies kann auch eine interne CA sein.
    Wenn Sie OCS einsetzen, dann sollte auch die UM-Rolle ein Zertifikat einer CA haben, damit die Communicator Clients ihre Voicemail anrufen können.
  • Receive Connector Konfiguration (Receiveconnector)
    By Default hat ein Exchange HT genau einen Receive Connector, der eine Anmeldung per Kerberos und TLS erlaubt. Passen Sie bei der Erstellung weiterer Receive Connectoren auf, dass diese Funktion nicht verbaut wird, z.B. indem sie einen Connector so umstellen,. dass er aus dem Internet "nur anonym" annehmen kann. Im Extremfall sollten sie einen eigenen Receive Connector einrichten, der für die IP-Adresse der UM-Rolle gilt
  • Kerberos
    Anmelden bedeutet unter Exchange natürlich "Kerberos". Prüfen Sie, dass zum FQDN des HT-Servers auch ein SPN vorhanden ist. Kerberos SPN

Ansonsten können natürlich immer noch per NETMON o.ä. kontrollieren, welche Kommunikationsverbindungen nicht zustande kommen.

Eventlog und Debugging

Wenn man aber einen Fehler wirklich etwas genauer nachspüren möchte, dann kann man bei Exchange 2007 natürlich auch noch ein erweitertes Debugging aktivieren. Dazu müssen Sie allerdings die PowerShell bemühen: (Einschalten und Ausschalten)

get-EventLogLevel -Identity "*um*" | Set-EventLogLevel -Level high
get-EventLogLevel -Identity "*um*" | Set-EventLogLevel -Level lowest

Dann sehen Sie aber im Eventlog auch alle normalen Rufmeldungen, die ansonsten nicht

Event Type: Information
Event Source: MSExchange Unified Messaging
Event Category: UMCore 
Event ID: 1004
User: N/A
Computer: NAWSV002

Description: A call was received with the following parameters: Calling Party: 
"sip:anonymous@192.168.100.111;User=phone", Called Party: "sip:680@nawsv002", 
Diversion Information: "<null>", Call ID "2bfc4c98-a2778-1@192.168.100.111".

Weitere Links