Posted in

Microsoft Exchange Server Pipeline Tracing Nedir? Nasıl Kullanılır?

Nedir?

En geniş cümleyle, Pipeline Tracing, Microsoft Exchange Server’da, özellikle mesaj akışı (mail flow) sorunlarını detaylı biçimde analiz etmek amacıyla kullanılan bir tanılama ve izleme aracıdır.

Biraz daha açacak olursak, Pipeline Tracing, belirli bir göndericiye (sender) ait e-posta mesajlarının Exchange sunucusundaki Transport Pipeline (Taşıma Hattı) üzerinden nasıl geçtiğini detaylı olarak kaydeder. Bu işlem sırasında her bir mesaj için snapshot dosyaları (anlık görüntüler) oluşturulur ve bu dosyalarda, mesajın hangi aşamalardan geçtiği, hangi transport agent’lar tarafından ne tür işlemler yapıldığı gibi bilgiler ayrıntılı şekilde yer alır. Mesaj transport hattında ilerlerken her bir adımdan önce ve adım tamamlandırktan sonra mesajın kopyası alınır. Dolayısı ile bir maile ait onlarca snapshot dosyaları oluşabilmektedir. Bu sebeple pipeline tracing aracını uzun süre çalıştırmanız önerilmediği gibi, çalıştırdığınız süre boyunca da disk doluluğunu izlemeniz ve sürekli olarak kontrol etmeniz önerilir.

Ayrıca mail kopyalarını oluşturması sebebiyle, mailin içeriği bu kopyalar ile okunabilir olduğundan PipelineTracing açılırken snapshot dosyalarının oluşturulması istenen klasör(ler)e yetkili kişiler dışındaki kullanıcıların erişememesi için gerekli önlemleri almanız şiddetle tavsiye edililir.

Ne İçin Kullanılır?

  1. Mesaj akışındaki sorunları teşhis etmek:

    • E-postaların neden geciktiği, yönlendirilmediği veya beklenmedik şekilde işlendiği durumları analiz etmek.

  2. Transport agent’ların etkisini görmek:

    • Her bir agent’ın (örneğin bir spam filtresi, transport rule veya DLP agent) mesaj üzerinde ne tür değişiklikler yaptığını görmek.

  3. Kural veya agent testi yapmak:

    • Yeni yazılmış bir Transport Agent, Transport Rule, veya başka bir özelleştirme doğru çalışıyor mu diye kontrol etmek.

  4. Debug (Hata Ayıklama):

    • Özellikle üçüncü parti agent’ların etkilerini ve hatalarını analiz etmek için kullanılır.

 

Nasıl Kullanılır?

  • Ortamımda DC (Server 2022) ve Exchange Server (2019) lab ortamı olması dolayısıyla aynı makineye kurulu durumdadır. Prod ortamlarında bu kesinlikle önerilmez. Ortama herhangi bir client vs kurmakla uğraşmamak adına da mail gönderimlerini owa üzerinden sağlıyor olacağım.

Örneğimizi daha iyi anlayabilmek için öncelikle Exchange için bir transport agent yazdım. Bu agent gönderilen her mailin subject kısmına, gönderen kişinin mail adresini ekliyor olacak. Ayrıca mailin alt tarafına (Append the Disclaimer) belirttiğimiz ifadeyi ekleyen bir transport rule’ umuz olsun. Fakat senaryo gereği bu durumları henüz bilmiyoruz. Bizim kullandığımız agent bir imza programı ya da spam filtresi de olabilirdi.

Şimdi bu agent kodunu derleyerek oluşan dll’i exchange sunucuya kopyalıyorum.

Exchange üzerindeki transport agentlarımıza göz gezdirmek istersek;

Get-TransportAgent

komutu ile listeleyebiliriz.

Kopyaladığımız dll dosyasını exchange sunucunun kullanabilmesi için;

Install-TransportAgent -Name “Pipeline_Test” -TransportAgentFactory “Test_Agent_For_Pipeline.MyAgentFactory” -AssemblyPath C:\Test-Agent\Test_Agent_For_Pipeline.dll

komutunu kullanmamız gerekiyor. Burada Name parametresi Transport Agent için kullancağım isim, AssemblyPath parametresi dll dosyasının bulunduğu full path, TransportAgentFactory parametresi ise dll projemin Test_Agent_For_Pipeline namespace’ine sahip MyAgentFactory sınıf adına sahip SmtpReceiveAgentFactory sınıfından türetilen bir sınıf kullanarak oluşturduğunu belirtir.

Komut sontasında çıktımız aşağıdaki gibi olmaktadır.

Yapılan işlemin geçerli olması için MsExchangeTransport servisini restart etmemiz gerektiğini belirtmektedir.

İki kere restart etmemek adına, yüklediğimiz agent’ı ENABLE edelim. ve daha sonra servisi restart edelim.

Artık transport agent yüklü ve enable durumdadır. Dilersek, Get-TransportAgent komutu ile sağlamasını yapabiliriz. En aşağıda Pipeline_test şeklinde yüklü ve enable olduğunu görüyoruz.

Şimdi gelelim baştaki konuştuğumuz senaryoya. Buraya kadarki işlemler senaryomuzu gerçekleştirebilmemiz için bize gerekli olan adımlardı.

Senaryomuzu görebilmek adına mustafaemre.gul@m3g.com.tr mail adresine sahip kullanıcıdan, stduser@m3g.com.tr mail adresine sahip kullanıcıya bir eposta atıyorum.

Görüğünüz üzere senaryo gereği belirtilen mailin subjectine ve içerğine eklenen metinler mevcut. Exchange admini olarak bunu farkettiniz ve sorun genel ya da sunucu bazlı bir problem. Client,outlook, outlook profile vs bazlı kontrolleri yaptınız fakat bişey çıkmadı.

Hemen imdadımıza koşan mesage tracking log’lara bakmayı akıl ettiniz ve aşağıdaki gibi komutu girerek ilgili logların içeriğine bakmak istediniz.

Gördüğünüz gibi akışta bir yerlerde subject değişmiş gözükmekte. Bu komutun çıktısını bir değişkene atarak Format-List * ile içeriklerine baktığımızda da net bir sonuç vermeyecektir. Loglardan incelediğinizde göreceksiniz ki, tüm maillerin messageid ‘si de aynı.

Bu noktada Pipeline Tracing kullanmak en mantıklı seçenektir. Maillerin ulaşmaması gibi durumlarda messagetrackinglog üzerinde Fail event ‘ına sahip loglar göreceğiniz için içerik ile ilgili olan maillerde Pipeline Tracing kullanmak daha olasıdır. Çünkü messagetrackinglog mailin içeriği ile ilgilenmez.

Pipeline Tracing kullanabilir duruma gelmeniz için exchange üzerinde transport servisleri için (TransportService – MailboxTransportService) pipeline tracing komutlarını çalıştırmanız gerekmektedir.

Set-TransportService -Identity m3gdc.m3g.test -PipelineTracingEnabled $true -PipelineTracingPath “c:\Transport_PipelineTracing” -PipelineTracingSenderAddress “mustafaemre.gul@m3g.com.tr”

Set-MailboxTransportService -Identity m3gdc.m3g.test -PipelineTracingSenderAddress “mustafaemre.gul@m3g.com.tr” -PipelineTracingEnabled $true -PipelineTracingPath “c:\MailboxTransport_PipelineTracing”

Identity : exchange sunucu ismi

PipelineTracingSenderAddress : izleme yapılacak mail adresi

PipelineTracingEnabled : izlemenin enable/disable durumu

PipelineTracingPath : mesaj kopyalarının alınacağı dizin.

  • (Eğer PipelineTracingPath parametresini kullanmazsanız mesaj kopyaları default lokasyonda oluşacaktır. Default dizinler transport service için : %ExchangeInstallPath%\TransportRoles\Logs\Hub\PipelineTracing mailbox transport service için : %ExchangeInstallPath%\TransportRoles\Logs\Mailbox\PipelineTracing şeklindedir.)

Pipeline Tracing ‘i enable etmeden önce sunucumuz üzerindeki durumuna bir bakarsak aşağıdaki gibi bir görüntü ile karşılaşırız, çünkü pipeline tracing default durumda kapalıdır.

Yukarıdaki Set komutlarını çalıştırdıktan sonra kontrol ettiğimizde ise aşağıdaki gibi olacaktır.

  • Pipeline Tracing enable duruma geldikten sonra, belirttiğiniz şartlara hit eden mesajlar olduğu taktirde klasörler otomatik olarak oluşturulacak ve mesaj kopyaları bu dizinlerin altında görünecektir.

Yukarıdaki mail trafiğini tekrar yaratarak ilgili dizinlerde logların oluşup oluşmadığını kontrol ediyorum.

Logların içeriği ve hangi akışta hangi logun oluştuğu başka bir makale konusu olsa da, logların ortak özelliğine kısaca değinmek gerekirse;

Exchange sunucusu her transport ve routing adımında mailin header ‘larına aşağıdaki gibi loglar ekleyecektir.

X-CreatedBy: MessageSnapshot-Begin injected headers
X-MessageSnapshot-UTC-Time: 2025-05-28T21:37:15.576Z
X-MessageSnapshot-Record-Id: 253403070466
X-MessageSnapshot-Source: OnSubmittedMessage
X-Sender: MustafaEmre.GUL@m3g.com.tr
X-Receiver: stduser@m3g.com.tr
X-EndOfInjectedXHeaders: MessageSnapshot-End injected headers

Hem kafa karıştırmaması hem de ekran görüntüleriyle burayı doldurmamak adına dosyaların tüm içeriklerini ve görüntülerini paylaşmayacağım. Fakat Original.eml dosyasından başlayarak içeriklerini incelediğinizde başlığın nerede değiştiğini ve bu değişime sebep olan nedeni görebilirsiniz.

Benim seneryomda, logları inceledikten sonra, mail içeriğine eklenen (Disclaimer) metin sebebi aşağıdaki gibidir.

Routing0012.eml dosyasında içeriğin değiştiğini görebiliyorsunuz. Bir önceki adımda olmayan metin bir sonraki adımın sonunda eklenmiş ve hangi adımın sonunda olduğu ise X-MessageSnapshot-Source alanında yazmaktadır. Yazdığımız bir transport rule buna sebebiyet vermiş ve transport rule ‘lar işlenirken belirttiğimiz şekilde metni mailin içeriğine eklemiştir.

Mailin subject değişiminin sebebi ise aşağıdaki gibidir.

Subject değişiminin değişikliğini SmtpReceive0009.eml dosyasında buldum. Loglarda da görüldüğü üzere bir önceki SmtpReceive0008.eml dosyasında bu değişiklik mevcut değil. Mesaj başlığı bu noktaya kadar aynı gelip, SmtpReceive009.eml dosyasında başlık değişmiş gözükmektedir. Bu loglara dayanarak transport katmanımızda çalışan Pipeline_Test transport agent ‘ının bu değişikliğe sebep olduğunu görüyoruz.

Son logda dikkatinizi bişey çekti mi? Tarih bir anda geriye gitmiş gözüküyor. Peki bu tarih değişikliği sebebinin de Pipeline_Test transport agent ‘ı olduğunu söyleyebilir miyiz?

Kesinlikle evet! Log yalan söylemez. Çünkü seneryonun başında özellikle belirtmediğim bir durum bu. Transport agent yazarken mesajın tarihini oynadığım bir kod alanı mevcut. Bu kod sebebiyle Pipeline_Test transport agent ‘ı görevini yapmış gözüküyor ve tarihi de değiştirmiş olduğu log üzerinden anlaşılıyor.

Faydalı olması dileğiyle.

Microsoft’ un pipeline tracing ile ilgili makalesine link üzerinden erişebilirsiniz.

Exchange konuları ile ilgili diğer makaleler için link.

 

 

2 thoughts on “Microsoft Exchange Server Pipeline Tracing Nedir? Nasıl Kullanılır?

  1. RecepYuksel says:

    Emre bey elineze sağlık çok güzel makale olmuş.

    1. Çok teşekkür ederim Recep Bey. Sizin gibi sahada tecrübeli, yıllarını IT ‘ye vermiş bir kişiden beğeni almak ayrıca bir onur kaynağı.

Leave a Reply

Your email address will not be published. Required fields are marked *