logi Exchange Transport

Logi Exchange Transport to dzienniki usługi transportowej tego serwera, rejestrujące trasę i status każdej wiadomości.

Rola logów Exchange Transport w obsłudze wiadomości

Logi Exchange Transport to zestaw dzienników tworzonych przez usługi transportowe Microsoft Exchange Server podczas przyjmowania, przetwarzania i przekazywania poczty. Najczęściej analizowanym rodzajem są message tracking logs, czyli logi śledzenia wiadomości. Rejestrują one zdarzenia dotyczące konkretnej wiadomości, między innymi jej przyjęcie przez usługę transportową, przekazanie do kolejki, dostarczenie do skrzynki, wysłanie do innego serwera albo odrzucenie. Wpis zawiera identyfikator wiadomości, nadawcę, odbiorcę, czas zdarzenia, nazwę serwera oraz typ wykonanej operacji.

Wpis w logu śledzenia nie jest pełną kopią wiadomości i nie zastępuje jej nagłówków. Jego zadaniem jest opisanie przebiegu obsługi w systemie transportowym. Dzięki temu można ustalić, czy wiadomość dotarła do serwera Exchange, czy została przekazana dalej oraz na którym etapie pojawił się problem. W środowisku z kilkoma serwerami konieczne jest uwzględnienie serwera, który zapisał dany wpis, ponieważ każdy serwer prowadzi własne dzienniki.

Rodzaje dzienników usługi transportowej

Poza message tracking logs Exchange Server może zapisywać logi protokołu SMTP. Receive protocol log opisuje komunikację z klientem lub serwerem, który dostarcza wiadomość do usługi Receive connector. Send protocol log dotyczy połączeń wychodzących nawiązanych przez Send connector. Wpisy mogą zawierać adresy IP, nazwy hostów, kolejne komendy SMTP, odpowiedzi serwera zdalnego oraz informacje o zakończeniu połączenia. Protocol logging jest przydatny wtedy, gdy samo śledzenie wiadomości pokazuje próbę wysyłki, ale nie wyjaśnia odpowiedzi otrzymanej podczas sesji SMTP.

Exchange udostępnia także connectivity logging, który koncentruje się na połączeniach nawiązywanych przez usługę transportową, oraz pipeline tracing, używany do szczegółowego obserwowania przetwarzania wiadomości przez agenty transportowe. Pipeline tracing powinien być uruchamiany ostrożnie i tylko dla kontrolowanego przypadku diagnostycznego, ponieważ tworzy znacznie bardziej szczegółowy materiał niż standardowe logi śledzenia. W zależności od konfiguracji można spotkać również logi agentów transportowych, które wskazują działania podejmowane przez reguły i rozszerzenia uczestniczące w przetwarzaniu wiadomości.

Odczytywanie trasy, statusu i przyczyny zatrzymania

Podstawowym narzędziem PowerShell do wyszukiwania informacji w message tracking logs jest polecenie Get-MessageTrackingLog. Filtrowanie po nadawcy, odbiorcy, temacie, identyfikatorze wiadomości albo przedziale czasu ogranicza wynik do zdarzeń związanych z konkretną korespondencją. W praktyce szczególnie ważne są pola Timestamp, EventId, Source, Sender, Recipients, MessageId i ServerHostname. Zdarzenia takie jak RECEIVE, SEND, DELIVER, FAIL, DEFER i REDIRECT opisują odpowiednio przyjęcie, wysłanie, dostarczenie, błąd, odroczenie lub przekierowanie obsługi.

Brak zdarzenia DELIVER nie zawsze oznacza, że wiadomość została utracona. Jeżeli występuje DEFER, wiadomość mogła pozostać w kolejce z powodu chwilowego problemu z DNS, połączeniem TCP, odpowiedzią serwera zdalnego albo ograniczeniem ustanowionym przez transport. Zdarzenie FAIL wymaga zestawienia z kodem SMTP, komunikatem błędu oraz wpisami w logu Send protocol. Przy analizie trzeba również porównywać czas lokalny serwera z czasem zapisanym w dzienniku, sprawdzać różnice między identyfikatorem nagłówka Message-ID a wewnętrznymi identyfikatorami Exchange oraz uwzględniać możliwość ponownego przetworzenia tej samej wiadomości.

Diagnostyka logów bez zacierania śladu zdarzeń

Analizę należy rozpocząć od ustalenia zakresu czasu, nadawcy, odbiorcy i kierunku przepływu wiadomości. Następnie warto odtworzyć sekwencję zdarzeń na podstawie message tracking logs, a dopiero później sięgnąć do logów SMTP i logów połączeń. Taki porządek pozwala rozdzielić problem przyjęcia wiadomości, przetwarzania wewnętrznego i dostarczenia do zewnętrznego serwera. W przypadku wielu serwerów Exchange trzeba zebrać dane z każdego serwera, który mógł uczestniczyć w trasie.

Logi podlegają retencji i rotacji, dlatego starsze wpisy mogą zostać automatycznie usunięte po osiągnięciu limitu wieku albo rozmiaru katalogu. Ustawienia dotyczące transportu można sprawdzać poleceniami Get-TransportService oraz Get-FrontEndTransportService, zależnie od analizowanej usługi. Zmiana poziomu logowania powinna być odnotowana wraz z czasem rozpoczęcia i zakończenia testu. Przy diagnostyce komputera, na którym używany jest klient poczty, logi Exchange Transport pomagają odróżnić błąd aplikacji klienckiej od problemu występującego już po stronie serwera, kolejki lub komunikacji SMTP. Naprawa takiego przypadku wymaga zachowania oryginalnych wpisów, ustalenia konkretnego etapu awarii i dopiero potem wprowadzenia zmian konfiguracyjnych.