Śledzenie wiadomości, weryfikowanie czy dotarła ona do adresata oraz upewnienie się czy wiadomość była przesłana drogą taką, jaką się spodziewamy może okazać się niełatwym zadaniem. Gdy wiadomość dotrze już do adresata, z nagłówka wiadomości możemy dowiedzieć się, jaką drogę przebyła. Często są jednak sytuacje, że nie mamy możliwości odczytać wiadomości dostarczonej do adresata i chcemy „wyśledzić” naszą wiadomość.
W systemie Microsoft Exchange 2013 możemy posłużyć się poleceniami Exchange Management Shell (EMS) i uzyskać informacje dotyczące trasy naszej wiadomości. W artykule tym opiszę jak odczytywać logi transportowe za pomocą EMS w systemie Microsoft Exchange 2013 oraz przedstawię krótko alternatywne sposoby odczytywania trasy naszej wiadomości. Przesyłanie wiadomości w systemie Microsoft Exchange 2013 zostało zmodyfikowane i jak wiadomo nie ma już serwera z rolą HUB Transport (jak w przypadku Microsoft Exchange 2007/2010). Odpowiedzialność za przesyłanie wiadomości znajduje się w usługach znajdujących się na serwerze z rolą Mailbox: Transport Service, Mailbox Transport Submission Service oraz Mailbox Transport Delivery Service. Więcej informacji o przesyłaniu wiadomości w systemie Microsoft Exchange 2013 można znaleźć tutaj: Mail Flow
Pobieranie danych z logów transportowych
Pierwszym krokiem jest wykonanie odpowiedniego zapytania w EMS. Jeśli wiemy, kto był nadawcą wiadomości, a kto odbiorcą wykonujemy poniższe 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 widać, iż nasza wiadomość była na trzech serwerach. Jednak to, co się z nią działo na poszczególnych serwerach, przez jakie usługi transportowe na nich przechodziła, możemy odczytać za pomocą dwóch kolumn: EventID (Zdarzenie) oraz Source (Źródło). Aby ułatwić odczytanie tych informacji, poniżej przedstawiam opis najczęstszych zdarzeń oraz źródeł tych zdarzeń. Na tej podstawie możemy dowiedzieć się o trasie naszej wiadomości.
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 została zastosowana dla danej wiadomości, a Malware Filter Agent zarejestruje informacje dotyczące przeskanowania wiadomości. |
DEFER | Dostarczenie wiadomości było/jest opóźnione np. może wystąpić, gdy nie można dostarczyć wiadomości do adresata, ponieważ baza danych, w której znajduje się skrzynka była/jest odmontowana. |
DELIVER | Wiadomość została dostarczona do lokalnej skrzynki. |
DSN | Wygenerowała została wiadomość typu Delivery Status Notification (DSN) |
EXPAND | Przeprowadzone zostało rozwinięcie listy dystrybucyjnej |
FAIL | Dostarczanie wiadomości nie powiodło się. |
HADISCARD | Redundantna wiadomości (shadow message) została usunięta, ponieważ oryginalna wiadomość została poprawnie dostarczona do następnego celu (Next hop). Więcej informacji można znaleźć Shadow Redundancy. |
HARECEIVE | Redundantna wiadomość (shadow message) została otrzymana przez serwer w Database Availability Group (DAG) lub przez serwer w tym samym Active Directory Site |
HAREDIRECT | Wygenerowana została wiadomość redundantna (shadow message) |
HAREDIRECTFAIL | Utworzenie redundantnej wiadomość (shadow message) nie powiodło się. |
RECEIVE | Wiadomość została odebrana przez komponent SMTP Receive usługi Transport Service lub odebrana z katalogów Pickup lub Replay (źródło: SMTP) Wiadomość została dostarczona ze skrzynki pocztowej do usługi Mailbox Transport Submission Service (źródło: STOREDRIVER). |
RESUBMIT | Wiadomość została automatycznie przesłana ponownie z Safety Net. Więcej informacji można znaleźć tutaj: Safety Net. |
RESUBMITFAIL | Ponowne automatyczne wysłanie wiadomości z Safety Net nie powiodło się. |
SEND | Wiadomość została wysłana za pomocą protokołu SMTP pomiędzy usługami transportowymi. |
SUBMIT | Usługa Mailbox Transport Submission Service dostarczyła z sukcesem wiadomość do usługi Transport Service |
SUBMITFAIL | Dostarczenie wiadomość od usługi Mailbox Transport Submission Service do usługi Transport Service nie powiodło się |
Źródło | Opis |
ADMIN | Źródłem zdarzenia była interwencja administratora. Np. administrator usunął wiadomość z kolejki wiadomości. |
AGENT | Źródłem zdarzenia był agent transportowy |
DSN | Źródłem zdarzenia był Delivery Status Notification (DSN), – czyli na przykład, raport o niedostarczeniu wiadomości |
REDUNDANCY | Źródłem zdarzenia był komponent Shadow Redundancy. Więcej informacji można znaleźć tutaj: Shadow Redundancy. |
ROUTING | Źródłem zdarzenia był komponent ustalający ścieżkę wiadomości znajdujący się w usłudze transportowej. |
SAFETYNET | Źródłem zdarzenia był komponent Safety Net. Więcej informacji można znaleźć tutaj Safety Net. |
SMTP | Źródłem zdarzenia był jeden z poniższych komponentów usługi Transport Service: SMTP send – wysyłanie wiadomości za pomocą protokołu SMTP SMTP recieve – odbieranie wiadomości za pomocą protokołu SMTP |
STOREDRIVER | Źródłem zdarzenia był komponent komunikujący się ze skrzynka pocztową na lokalnym serwerze wykorzystując MAPI, czyli usługa Mailbox Transport Submission Service lub Mailbox Transport Delivery Service |
Odczytywanie informacji o przepływie wiadomości
Teraz omówimy sobie zdarzenia, jakie dotyczyły przesłanej przykładowej wiadomości. Prześledźmy, zatem wynik naszego zapytania i posługując się powyższymi tabelkami omówimy, co się działo w każdym z wierszy. Dla czytelności dodałem nr wierszy do naszego logu.
![]()
- W wierszu nr 1 mamy zdarzenie RECEIVE, a źródłem jest STOREDRIVER. To nam mówi, iż wiadomość została dostarczona ze skrzynki pocztowej do usługi Mailbox Transport Submission Service znajdującej się na serwerze DortmundEXA01. Komunikacja ta odbyła się w obrębie tego samego serwera.
- W wierszu nr 2 mamy zdarzenie HAREDIRECTFAIL, co oznacza, iż nastąpiła próba wygenerowania wiadomości redundantnej na serwerze MilanEXM01 zakończona niepowodzeniem.
- W wierszu nr 3 mamy zdarzenie RECEIVE, a źródłem jest SMTP. Oznacza to, iż wiadomość została odebrana przez komponent SMTP Receive usługi Transport Service. Serwerem wysyłającym (klient) był serwer DortmundEXA01, a serwerem odbierającym (serwer) był serwer MilanEXM01.
- Wiersz nr 4 posiada zdarzenie SUBMIT, a jego źródłem jest STOREDRIVER. Z tabel zawierających opisy zdarzeń odczytujemy, iż usługa Mailbox Transport Submission Service dostarczyła z sukcesem wiadomość do usługi Transport Service. Serwerem wysyłającym (klient) był serwer DortmundEXA01, a serwerem odbierającym (serwer) był serwer MilanEXM01.
Zatrzymajmy się tutaj na chwilę. Wiersz nr 3 i wiersz nr 4, tak naprawdę opisuje nam to samo zdarzenie, jednakże zarejestrowane przez dwie usługi (wysyłającą i odbierającą) na dwóch różnych serwerach. Oba mówią nam o dostarczeniu wiadomości od usługi Mailbox Transport Submission Service na serwerze DortmundEXA01 do usługi Transport Service na serwerze MilanEXM01.
- Wiersz nr 5 zawiera zdarzenie AGENTINFO, co może wskazywać na procesowanie reguł transportowych dla tej wiadomości lub skanowanie przez Malware Filter Agent na serwerze MilanEXM01.
- W wierszu nr 6 mamy zdarzenie HAREDIRECTFAIL, co oznacza, iż nastąpiła próba wygenerowania wiadomości redundantnej na serwerze LondonEXA01 zakończona niepowodzeniem.
- Wiersz nr 7 zawiera zdarzenie RECEIVE, a źródłem jest SMTP. Oznacza to, iż wiadomość została odebrana przez komponent SMTP Receive usługi Transport Service. Serwerem wysyłającym (klient) był serwer MilanEXM01, a serwerem odbierającym (serwer) był serwer LondonEXA01.
- Wiersz nr 8 zawiera zdarzenie SEND, a źródłem jest SMTP. To z kolei oznacza, że wiadomość została wysłana za pomocą protokołu SMTP pomiędzy usługami transportowymi. Serwerem wysyłającym (klient) był serwer MilanEXM01, a serwerem odbierającym (serwer) był serwer LondonEXA01.
Znów zatrzymajmy się na chwilę. Wiersz nr 7 i 8 opisuje nam to samo zdarzenie zarejestrowane przez dwie różne usługi transportowe na dwóch różnych serwerach. Jedna mówi o wysłaniu wiadomości (wiersz nr 8), a druga o odebraniu tej samej wiadomości (wiersz nr 7). Ponieważ z poprzednich zdarzeń wiedzieliśmy, iż wiadomość znajdowała się w usłudze Transport Service na serwerze MilanEXM01, to wiersz nr 7 i 8 mówi nam o przesłaniu wiadomości pomiędzy usługą Transport Service na serwerze MilanEXM01, a usługą Transport Service na serwerze LondonEXA01.
- Wiersz nr 9 zawiera zdarzenie AGENTINFO, co może wskazywać na skanowanie wiadomości przez Malware Filter Agent na serwerze LondonEXA01.
- Wiersz nr 10 zawiera zdarzenie DELIVER, a źródłem jest STOREDRIVER. Z naszych tabel wynika, że w takim przypadku wiadomość została dostarczona do skrzynki pocztowej odbiorcy. Usługą odpowiedzialną za dostarczenie wiadomości do skrzynki jest usługa Mailbox Transport Delivery Service.
- Wierz nr 11 posiada zdarzenie SEND, a źródłem jest SMTP. To oznacza, że wiadomość została wysłana za pomocą protokołu SMTP pomiędzy usługami transportowymi. Serwerem wysyłającym (klient) był serwer LondonEXA01, a serwerem odbierającym (serwer) był także serwer LondonEXA01. Z poprzednich zdarzeń wiedzieliśmy, ze wiadomość została dostarczona do usługi Transport Service na serwerze LondonEXA01, wiec zdarzenie SEND w tym przypadku mówi nam o wysłaniu wiadomości od usługi Transport Service do usługi Mailbox Transport Delivery Service.
Poniżej znajduje się zobrazowanie trasy wiadomości, gdzie cyfry odpowiadają nr wierszy z naszego zapytania pobrane z logów na odpowiednich serwerach.
![]()
Podsumujmy, zatem gdzie po kolei znajdowała się nasza wiadomość.:
1. Wiadomość została wysłana ze skrzynki znajdującej się na serwerze DortmundEXA01
2. Wiadomość znajdowała się w usłudze Mailbox Transport Submission Service na serwerze DortmundEXA01
3. Następnie wiadomość znajdowała się w usłudze Transport Service na serwerze MilanEXM01.
4. Potem wiadomość znajdowała się w usłudze Transport Service na serwerze LondonEXA01.
5. Później wiadomość znajdowała się w usłudze Mailbox Transport Delivery Service na serwerze LondonEXA01.
6. Następnie wiadomość została dostarczona do skrzynki na serwerze LondonEXA01.
Korzystanie z Delivery Reports
Szybszym i łatwiejszym sposobem do śledzenia naszej wiadomości jest skorzystanie z Delivery Reports (Raporty doręczeń). Jest to narzędzie śledzenia wiadomości znajdujące się w konsoli Exchange Administration Center (EAC). Można go użyć do wyszukiwania i śledzenia statusu przepływu wiadomości e-mail wysyłanych do lub od użytkowników znajdujących się w GAL, z pewnym zastrzeżeniem. Można śledzić informacje dotyczące wiadomości wysyłanych przez lub otrzymanych od konkretnej skrzynki pocztowej w organizacji. Więcej informacji na temat Delivery Reports znajdziesz tutaj: Track messages with delivery reports.
Korzystając Delivery Reports dla naszej wiadomości dostajemy poniższą informację:
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 wiadomości z nagłówka
Informację, przez jakie serwery przechodziła nasza wiadomość można także odczytać z nagłówka odebranej wiadomości oraz analizatora wiadomości znajdującego się na stronie https://testconnectivity.microsoft.com/. Analizując nagłówek tej samej wiadomości dostajemy wynik:
![]()
Przeskok nr 4 mówi nam o przesłaniu wiadomości pomiędzy usługą Transport Service a usługą Mailbox Transport Delivery Service znajdujących się na tym samym serwerze.
Podsumowanie
Jak widać mamy kilka sposobów na sprawdzenie, w jaki sposób nasza wiadomości dotarła od nadawcy do adresata. Najszybszym i chyba najłatwiejszym sposobem jest wykorzystanie funkcjonalności Delivery Report zawartej w konsoli Exchange Admin Center. Jednakże, jeśli chcemy uzyskać szczegółowe informacje dotyczące wszelkich zdarzeń, jakie miały miejsce podczas przesyłania wiadomości (np. użycie Agentów Transportowych, poprawne lub niepoprawne wygenerowanie wiadomości redundantnych), wówczas należy skorzystać z Exchange Management Shell. Dodatkowo, jeśli chcemy prześledzić lub znaleźć informacje o wiadomościach wysyłanych od/do naszej organizacji gdzie nadawcą lub odbiorcą była osoba z poza GAL wówczas także będziemy zmuszeni do skorzystania z Exchange Management Shell.