Partager via

Śledzenie wiadomości w Microsoft Exchange 2013

  • Article

Sledzenie wiadomosci, weryfikowanie czy dotarla ona do adresata oraz upewnienie sie czy wiadomosc byla przeslana droga taka, jaka sie spodziewamy moze okazac sie nielatwym zadaniem. Gdy wiadomosc dotrze juz do adresata, z naglówka wiadomosci mozemy dowiedziec sie, jaka droge przebyla. Czesto sa jednak sytuacje, ze nie mamy mozliwosci odczytac wiadomosci dostarczonej do adresata i chcemy „wysledzic” nasza wiadomosc.

W systemie Microsoft Exchange 2013 mozemy posluzyc sie poleceniami Exchange Management Shell (EMS) i uzyskac informacje dotyczace trasy naszej wiadomosci. W artykule tym opisze jak odczytywac logi transportowe za pomoca EMS w systemie Microsoft Exchange 2013 oraz przedstawie krótko alternatywne sposoby odczytywania trasy naszej wiadomosci. Przesylanie wiadomosci w systemie Microsoft Exchange 2013 zostalo zmodyfikowane i jak wiadomo nie ma juz serwera z rola HUB Transport (jak w przypadku Microsoft Exchange 2007/2010). Odpowiedzialnosc za przesylanie wiadomosci znajduje sie w uslugach znajdujacych sie na serwerze z rola Mailbox: Transport Service, Mailbox Transport Submission Service oraz Mailbox Transport Delivery Service. Wiecej informacji o przesylaniu wiadomosci w systemie Microsoft Exchange 2013 mozna znalezc tutaj: Mail Flow

 

Pobieranie danych z logów transportowych

Pierwszym krokiem jest wykonanie odpowiedniego zapytania w EMS. Jesli wiemy, kto byl nadawca wiadomosci, a kto odbiorca wykonujemy ponizsze zapytanie:

Get-TransportService | Get-MessageTrackingLog -Sender user.01@fcit.pl -Recipients user.21@fcit.pl | Sort TimeStamp | ft EventId,Source,serverHostName,clientHostname,timestamp -AutoSize

 W wyniku tego zapytania otrzymujemy wynik:

Na pierwszy rzut oka widac, iz nasza wiadomosc byla na trzech serwerach. Jednak to, co sie z nia dzialo na poszczególnych serwerach, przez jakie uslugi transportowe na nich przechodzila, mozemy odczytac za pomoca dwóch kolumn: EventID (Zdarzenie) oraz Source (Zródlo). Aby ulatwic odczytanie tych informacji, ponizej przedstawiam opis najczestszych zdarzen oraz zródel tych zdarzen. Na tej podstawie mozemy dowiedziec sie o trasie naszej wiadomosci.

Nazwa zdarzenia

Opis

AGENTINFO

Zdarzenie to jest wykorzystywane przez agentów transportowych do rejestrowania danych niestandardowych. Np. Transport Rule Agent zarejestruje informacje o regule transportowej, która zostala zastosowana dla danej wiadomosci, a Malware Filter Agent zarejestruje informacje dotyczace przeskanowania wiadomosci.

DEFER

Dostarczenie wiadomosci bylo/jest opóznione np. moze wystapic, gdy nie mozna dostarczyc wiadomosci do adresata, poniewaz baza danych, w której znajduje sie skrzynka byla/jest odmontowana.

DELIVER

Wiadomosc zostala dostarczona do lokalnej skrzynki.

DSN

Wygenerowala zostala wiadomosc typu Delivery Status Notification (DSN)

EXPAND

Przeprowadzone zostalo rozwiniecie listy dystrybucyjnej

FAIL

Dostarczanie wiadomosci nie powiodlo sie.

HADISCARD

Redundantna wiadomosci (shadow message) zostala usunieta, poniewaz oryginalna wiadomosc zostala poprawnie dostarczona do nastepnego celu (Next hop).

Wiecej informacji mozna znalezc Shadow Redundancy.

HARECEIVE

Redundantna wiadomosc (shadow message) zostala otrzymana przez serwer w Database Availability Group (DAG) lub przez serwer w tym samym Active Directory Site

HAREDIRECT

Wygenerowana zostala wiadomosc redundantna (shadow message)

HAREDIRECTFAIL

Utworzenie redundantnej wiadomosc (shadow message) nie powiodlo sie.

RECEIVE

Wiadomosc zostala odebrana przez komponent SMTP Receive uslugi Transport Service lub odebrana z katalogów Pickup lub Replay (zródlo: SMTP)

Wiadomosc zostala dostarczona ze skrzynki pocztowej do uslugi Mailbox Transport Submission Service (zródlo: STOREDRIVER).

RESUBMIT

Wiadomosc zostala automatycznie przeslana ponownie z Safety Net. Wiecej informacji mozna znalezc tutaj: Safety Net.

RESUBMITFAIL

Ponowne automatyczne wyslanie wiadomosci z Safety Net nie powiodlo sie.

SEND

Wiadomosc zostala wyslana za pomoca protokolu SMTP pomiedzy uslugami transportowymi.

SUBMIT

Usluga Mailbox Transport Submission Service dostarczyla z sukcesem wiadomosc do uslugi Transport Service

SUBMITFAIL

Dostarczenie wiadomosc od uslugi Mailbox Transport Submission Service do uslugi Transport Service nie powiodlo sie

  

Zródlo

Opis

ADMIN

Zródlem zdarzenia byla interwencja administratora. Np. administrator usunal wiadomosc z kolejki wiadomosci.

AGENT

Zródlem zdarzenia byl agent transportowy

DSN

Zródlem zdarzenia byl Delivery Status Notification (DSN), – czyli na przyklad, raport o niedostarczeniu wiadomosci

REDUNDANCY

Zródlem zdarzenia byl komponent Shadow Redundancy. Wiecej informacji mozna znalezc tutaj: Shadow Redundancy.

ROUTING

Zródlem zdarzenia byl komponent ustalajacy sciezke wiadomosci znajdujacy sie w usludze transportowej.

SAFETYNET

Zródlem zdarzenia byl komponent Safety Net. Wiecej informacji mozna znalezc tutaj Safety Net.

SMTP

Zródlem zdarzenia byl jeden z ponizszych komponentów uslugi Transport Service:

SMTP send – wysylanie wiadomosci za pomoca protokolu SMTP

SMTP recieve – odbieranie wiadomosci za pomoca protokolu SMTP

STOREDRIVER

Zródlem zdarzenia byl komponent komunikujacy sie ze skrzynka pocztowa na lokalnym serwerze wykorzystujac MAPI, czyli usluga Mailbox Transport Submission Service lub Mailbox Transport Delivery Service

 

Odczytywanie informacji o przeplywie wiadomosci

Teraz omówimy sobie zdarzenia, jakie dotyczyly przeslanej przykladowej wiadomosci. Przesledzmy, zatem wynik naszego zapytania i poslugujac sie powyzszymi tabelkami omówimy, co sie dzialo w kazdym z wierszy. Dla czytelnosci dodalem nr wierszy do naszego logu.

  • W wierszu nr 1 mamy zdarzenie RECEIVE, a zródlem jest STOREDRIVER. To nam mówi, iz wiadomosc zostala dostarczona ze skrzynki pocztowej do uslugi Mailbox Transport Submission Service znajdujacej sie na serwerze DortmundEXA01. Komunikacja ta odbyla sie w obrebie tego samego serwera.
  • W wierszu nr 2 mamy zdarzenie HAREDIRECTFAIL, co oznacza, iz nastapila próba wygenerowania wiadomosci redundantnej na serwerze MilanEXM01 zakonczona niepowodzeniem.
  • W wierszu nr 3 mamy zdarzenie RECEIVE, a zródlem jest SMTP. Oznacza to, iz wiadomosc zostala odebrana przez komponent SMTP Receive uslugi Transport Service. Serwerem wysylajacym (klient) byl serwer DortmundEXA01, a serwerem odbierajacym (serwer) byl serwer MilanEXM01.
  • Wiersz nr 4 posiada zdarzenie SUBMIT, a jego zródlem jest STOREDRIVER. Z tabel zawierajacych opisy zdarzen odczytujemy, iz usluga Mailbox Transport Submission Service dostarczyla z sukcesem wiadomosc do uslugi Transport Service. Serwerem wysylajacym (klient) byl serwer DortmundEXA01, a serwerem odbierajacym (serwer) byl serwer MilanEXM01.

Zatrzymajmy sie tutaj na chwile. Wiersz nr 3 i wiersz nr 4, tak naprawde opisuje nam to samo zdarzenie, jednakze zarejestrowane przez dwie uslugi (wysylajaca i odbierajaca) na dwóch róznych serwerach. Oba mówia nam o dostarczeniu wiadomosci od uslugi Mailbox Transport Submission Service na serwerze DortmundEXA01 do uslugi Transport Service na serwerze MilanEXM01.

  • Wiersz nr 5 zawiera zdarzenie AGENTINFO, co moze wskazywac na procesowanie regul transportowych dla tej wiadomosci lub skanowanie przez Malware Filter Agent na serwerze MilanEXM01.
  • W wierszu nr 6 mamy zdarzenie HAREDIRECTFAIL, co oznacza, iz nastapila próba wygenerowania wiadomosci redundantnej na serwerze LondonEXA01 zakonczona niepowodzeniem.
  • Wiersz nr 7 zawiera zdarzenie RECEIVE, a zródlem jest SMTP. Oznacza to, iz wiadomosc zostala odebrana przez komponent SMTP Receive uslugi Transport Service. Serwerem wysylajacym (klient) byl serwer MilanEXM01, a serwerem odbierajacym (serwer) byl serwer LondonEXA01.
  • Wiersz nr 8 zawiera zdarzenie SEND, a zródlem jest SMTP. To z kolei oznacza, ze wiadomosc zostala wyslana za pomoca protokolu SMTP pomiedzy uslugami transportowymi. Serwerem wysylajacym (klient) byl serwer MilanEXM01, a serwerem odbierajacym (serwer) byl serwer LondonEXA01.

Znów zatrzymajmy sie na chwile. Wiersz nr 7 i 8 opisuje nam to samo zdarzenie zarejestrowane przez dwie rózne uslugi transportowe na dwóch róznych serwerach. Jedna mówi o wyslaniu wiadomosci (wiersz nr 8), a druga o odebraniu tej samej wiadomosci (wiersz nr 7). Poniewaz z poprzednich zdarzen wiedzielismy, iz wiadomosc znajdowala sie w usludze Transport Service na serwerze MilanEXM01, to wiersz nr 7 i 8 mówi nam o przeslaniu wiadomosci pomiedzy usluga Transport Service na serwerze MilanEXM01, a usluga Transport Service na serwerze LondonEXA01.

  • Wiersz nr 9 zawiera zdarzenie AGENTINFO, co moze wskazywac na skanowanie wiadomosci przez Malware Filter Agent na serwerze LondonEXA01.
  • Wiersz nr 10 zawiera zdarzenie DELIVER, a zródlem jest STOREDRIVER. Z naszych tabel wynika, ze w takim przypadku wiadomosc zostala dostarczona do skrzynki pocztowej odbiorcy. Usluga odpowiedzialna za dostarczenie wiadomosci do skrzynki jest usluga Mailbox Transport Delivery Service.
  • Wierz nr 11 posiada zdarzenie SEND, a zródlem jest SMTP. To oznacza, ze wiadomosc zostala wyslana za pomoca protokolu SMTP pomiedzy uslugami transportowymi. Serwerem wysylajacym (klient) byl serwer LondonEXA01, a serwerem odbierajacym (serwer) byl takze serwer LondonEXA01. Z poprzednich zdarzen wiedzielismy, ze wiadomosc zostala dostarczona do uslugi Transport Service na serwerze LondonEXA01, wiec zdarzenie SEND w tym przypadku mówi nam o wyslaniu wiadomosci od uslugi Transport Service do uslugi Mailbox Transport Delivery Service.

 

Ponizej znajduje sie zobrazowanie trasy wiadomosci, gdzie cyfry odpowiadaja nr wierszy z naszego zapytania pobrane z logów na odpowiednich serwerach. 

 

Podsumujmy, zatem gdzie po kolei znajdowala sie nasza wiadomosc.:

1. Wiadomosc zostala wyslana ze skrzynki znajdujacej sie na serwerze DortmundEXA01

2. Wiadomosc znajdowala sie w usludze Mailbox Transport Submission Service na serwerze DortmundEXA01

3. Nastepnie wiadomosc znajdowala sie w usludze Transport Service na serwerze MilanEXM01.

4. Potem wiadomosc znajdowala sie w usludze Transport Service na serwerze LondonEXA01.

5. Pózniej wiadomosc znajdowala sie w usludze Mailbox Transport Delivery Service na serwerze LondonEXA01.

6. Nastepnie wiadomosc zostala dostarczona do skrzynki na serwerze LondonEXA01.

 

Korzystanie z Delivery Reports

Szybszym i latwiejszym sposobem do sledzenia naszej wiadomosci jest skorzystanie z Delivery Reports (Raporty doreczen). Jest to narzedzie sledzenia wiadomosci znajdujace sie w konsoli Exchange Administration Center (EAC). Mozna go uzyc do wyszukiwania i sledzenia statusu przeplywu wiadomosci e-mail wysylanych do lub od uzytkowników znajdujacych sie w GAL, z pewnym zastrzezeniem. Mozna sledzic informacje dotyczace wiadomosci wysylanych przez lub otrzymanych od konkretnej skrzynki pocztowej w organizacji. Wiecej informacji na temat Delivery Reports znajdziesz tutaj: Track messages with delivery reports.

Korzystajac Delivery Reports dla naszej wiadomosci dostajemy ponizsza informacje:

Delivery Report for User 21

Submitted

1/3/2014 2:45 PM DORTMUNDEXA01

The message was submitted to dortmundexa01.fc.local.

 

1/3/2014 2:45 PM dortmundexa01.fc.local

The message has been transferred from dortmundexa01.fc.local to MILANEXA01.fc.local.

 

1/3/2014 2:45 PM milanexa01.fc.local

Message was received by milanexa01.fc.local from DORTMUNDEXA01.fc.local.

 

1/3/2014 2:45 PM milanexa01.fc.local

The message has been transferred from milanexa01.fc.local to LONDONEXA01.fc.local.

 

1/3/2014 2:45 PM londonexa01.fc.local

Message was received by londonexa01.fc.local from MILANEXA01.fc.local.

 

1/3/2014 2:45 PM londonexa01.fc.local

The message has been transferred from londonexa01.fc.local to LONDONEXA01.fc.local.

Delivered

1/3/2014 2:45 PM londonexa01.fc.local

The message was successfully delivered.

 

Odczytanie trasy wiadomosci z naglówka

Informacje, przez jakie serwery przechodzila nasza wiadomosc mozna takze odczytac z naglówka odebranej wiadomosci oraz analizatora wiadomosci znajdujacego sie na stronie https://testconnectivity.microsoft.com/. Analizujac naglówek tej samej wiadomosci dostajemy wynik:

Przeskok nr 4 mówi nam o przeslaniu wiadomosci pomiedzy usluga Transport Service a usluga Mailbox Transport Delivery Service znajdujacych sie na tym samym serwerze.

 

Podsumowanie

Jak widac mamy kilka sposobów na sprawdzenie, w jaki sposób nasza wiadomosci dotarla od nadawcy do adresata. Najszybszym i chyba najlatwiejszym sposobem jest wykorzystanie funkcjonalnosci Delivery Report zawartej w konsoli Exchange Admin Center. Jednakze, jesli chcemy uzyskac szczególowe informacje dotyczace wszelkich zdarzen, jakie mialy miejsce podczas przesylania wiadomosci (np. uzycie Agentów Transportowych, poprawne lub niepoprawne wygenerowanie wiadomosci redundantnych), wówczas nalezy skorzystac z Exchange Management Shell. Dodatkowo, jesli chcemy przesledzic lub znalezc informacje o wiadomosciach wysylanych od/do naszej organizacji gdzie nadawca lub odbiorca byla osoba z poza GAL wówczas takze bedziemy zmuszeni do skorzystania z Exchange Management Shell.