Microsoft Exchange Server Pipeline Tracing Log Mimarisi

Microsoft Exchange Server Pipeline Tracing Log Mimarisi, Exchange Server e-posta sistemlerinde oluşan ileti bozulma nedenlerini analiz etmek için kullanılır.

E-posta güvenliğimizi sağlayan SMTP Gateway Güvenlik ürünleri e-posta güvenliğini sağlarken bazen de iletileri bozmakta ve bu bozulan iletirler de Exchange Server Pipeline Tracing log olay günlüklerinde saklanmaktadır.

Exchange Server Pipeline Tracing log mimarisi ile Exchange Server 2007 ile tanıştık ve güncel Microsoft Exchange Server sürümleri Exchange Server 2016 / 2019 da buözellik bulunmaktadır.

Microsoft Exchange Server Pipeline Tracing Log Mimarisi makalesi içinde aşağıdaki bilgilere sahip olacaksınız.

1. Microsoft Exchange Server Pipeline Tracing Log Mimarisi ve Tarihi

Microsoft Exchange Server Pipeline Tracing Log Mimarisi hakkında bilgi vermeden önce Exchange Server Mimarisini kısaca hatırlayalım ve Exchange Server Pipeline Tracing mimarisi nedir ve niçin kullanıldığını daha net bir şekilde anlamış olalım.

Exchange Server Role Konsolidasyon Süreci makalesinde Exchange Server mimarisinin geçirmiş olduğu evrimden bahsetmiştik. Exchge Server 2003 üzerinde bulunmayan bir çok hizmet  Exchange Server 2007 ile birlikte Exchange Role olarak hayatımıza girdi.

Şimdi ise güncel Microsoft Exchange Server e-posta sistemi Exchange Mailbox Role çatısı altında Exchange Services olarak hizmet vermektedir.

Microsoft Exchange Server Edge Role ise ilk günkü gibi ayrı bir Exchange Server olarak çalışmaya devam etmektedir.

Microsoft Exchange Edge Server Role, Exchange Server e-posts sistemlerine gelmekte olan iletileri ve gitmekte olan iletileri denetleyen Microsoft firmasının SMTP Gateway güvenlik ürünüdür.

Exchange Server Edge Role üzerine yükleyecek olduğumuz Anti Spam ürünleri ile e-posta sistemi için SMTP Gateway Güvenlik ihtiyacını karşılayabilir ve e-posta güvenliğini üçüncü başka bir yazılım ve donanıma bağlı kalmadan karşılayabiliriz.

Exchange Server Edge Role olmadan önce e-posta güvenliği için üçüncü taraf firmaların donanım ürünleri ve yazılımsal ürünleri kullanılmaktaydı. Bu ürünlerin kimileri Microsoft Exchange Server üzerinde çalışmakta kimileri ise arındırılmış bölge içinde hizmet vermekteydi.

Günümüzde kullanmış olduğumuz SMTP Gateway Güvenlik ürünleri de benzer şekilde çalışmaktadır.

Microsoft Exchange Server ile uyumlu olmayan yada yanlış ayarlar yapılan SMTP Gateway güvenlik ürünleri Exchange Server E-posta sistemine gelen ve giden iletilerin bozulmasına neden olabilir.

Exchange Server Pipeline Tracing mimarisinin anlaşılabilir olması için İleti bozulması cümlesini bunun için kullanmaktayım.

1.1. Exchange Server SMTP Gateway Güvenlik

Exchange Server 2003 ileti güvenliğini sağlamak için üretilen SMTP Gateway Güvenlik ürünlerinin uyumsuzluğu, iletilerin bozulmasına neden olmaktadyı.

Forefront Security for Exchange yazılımına kadar Microsoft’ un Exchange Server e-posta güvenliğini sağlamak için tasarlanmış bir güvenlik çözümü yoktu ve bu olumsuzluklar ve kısır döngü de bir çok kuruluş için problem oluşturmaktaydı.

SMTP Güvenliği istenildiği zaman iletilerin bozulması ile karşılaşılıyor ve üçüncü firmaların SMTP Gateway Güvenlik ürünleri ile Exchange Server bir çok kez uyumsuz çalışabiliyordu. Microsoft’ un Exchange Server için herhangi bir güvenlik politikası olmaması da kurumları zor duruma bırakıyordu.

Exchange Server Role konsolidasyon sürecinin başlamasına neden olan problemlere bir örneği paylaştık

Exchange Server 2007 ile birlikte Forefront Security güvenlik çözüm ailesi tasarlandı ve Microsoft, kendi ürünü olan Microsoft Exchange Server için SMTP Gateway Güvenlik çözümlerini geliştirmeye başladı.

Forefront for Exchange güvenlik ürünü Microsoft Exchange Server ile birlikte ve uyumlu çalışabiliyordu. Böylece, Microsoft Exchange Server 2003 için yanlış tasarlanan SMTP Gateway Güvenlik çözümleri artık kullanılmak zorunda değildi. Üstelik, Forefront for Exchange Güvenlik yazılımı üçüncü firmaların ürettiği SMTP Gateway Güvenlik çözümlerinin aksine çok daha esnek bir şekilde çalışabiliyordu.

1.2. Forefront for Exchange ile SMTP Gateway Güvenlik

Şimdi ise Exchange Server Mail flow mimarisini kısaca hatırlayalım. İnbound mail trafiği, yani harici SMTP Domain üzerinden gelen bir ileti Exchange Server organizasyonu içinde son kullanıcıya teslim edilmeden önce

1. Exchange Server Edge Role gelir ve burada denetlenir.
2. Edge Role denetlemiş olduğu iletileri Exchange Server Hub Transport Role aktarır ve burada ikinci bir denetime uğrar.
3. Exchange Server Hub Transport Role üzerinden denetime uğrayan ileti Exchange Mailbox Role aktarılır.
4. Yukarıda ki denetimlerden geçen ileti güvenliyse kullanıcımıza iletilir.

Outbound mail trafiği de benzer şekilde çalışmakta ve kurum için mail trafiğinde ise sadece Exchange Server Edge Role üzerinde denetim olmamakta.

Exchange Server Pipeline Tracing mimarisinin daha net anlaşılması için İleti bozulması cümlesini bir kez daha hatırlatıyorum…

Şimdi ise Forefront for Exchange mimarisini hatırlayalım.

• Forefront for Exchange güvenlik ürünü üç farklı Exchange Server Role üzerine de yüklenebilmektedir.
• Her bir Exchange Role üzerinde eş zamanlı 5 farklı engine çalışabilmektedir.

Ozamanlarda önerilen bir Mail Flow senaryosunu çizelim.

1. Exchange Edge Server Role üzerinde A,B ve C anti virus/anti spam yazılımları tarafından iletiler denetlensin ve güvenli ise Exchange Server Hub Transport Role ileti teslim edilsin.
2. Exchange Server Hub Transport Role üzerinde ise D,E, ve F anti virus/anti spam yazılımları tarafından iletiler denetlensin ve güvenli ise Exchange Server Mail Box Role ileti teslim edilsin.
3. ileti son kez Mailbox Role üzerinde G ve H anti virus/anti spam yazılımları tarafından iletiler denetlensin ve güvenli ise kullanıcı posta kutusuna bırakılsın.

Forefront Security for Exchange mimarisi esnekti ve Exchange E-posta organizasyonun da Microsoft Exchange Edge Server Role yok ise dört engine de Exchange Server Hub Transport Role üzerinde diğer dört engine ise Mailbox Role üzerinde çalışıp, SMTP Gateway Güvenlik çözümleri sağlanıyordu.

Forefront for Exchange yazılımı esnek çalışmaya devam ediyordu. Bir Role üzerine bir ileti A,B,C ve D anti virus/anti spam yazılımları tarafından denetlendikten sonra diğer sunucu üzerinde de istersek eğer aynı anti virus/anti spam yazılımları tarafından bir kez daha taranmasını yapabiliyorduk.

Neyse ki bu kadar esneklik daha doğrusu bu büyük pazarlama taktiğinden vazgeçildi ve Forefront for Exchange Security SP1 sürümü ile aynı anti virus/anti spam yazılımları ile denetlenen bir ileti tekrardan denetlenmesi engellendi.

2. Exchange Server Pipeline Tracing Log Nedir

Makalenin bir yerlerinde ileti bozulmasını not alalım dediğimi hatırlıyorum ve şimdi bu konuya sıra geldi.

Exchange Server 2003 ile uyumsuz çalışan SMTP Gateway güvenlik ürünleri gelen ve giden iletileri bozuyordu ve ileti bozulma olayı Forefront Security for Exchange mimarisi ile rafa kalkmasını beklerken paranoyak tasarımlar bu problemi taçlandırdı.

Forefront Security for Exchange SP1 sürümüne kadar son kullanıcılarımızın posta kutularına gelen iletilerin bazıları bozulmaya devam etti.

Forefront Security for Exchange üzerinde çalışan bazı anti virus/anti spam yazılımları gelen iletileri bozdu, ileti içinde barınan ekleri sildi, karakterler üzerinde değişiklik yaptı, iletileri okunmaz duruma getirdi ve Exchange Server yöneticileri bozulan iletilerin nedenlerini bulmak için Exchange Server Pipeline Tracing Log mimarisini kullanmaya başladı.

Exchange Server Pipeline Tracing Log özelliği ile iletinin neden bozulduğu ve çözümü için araştırma yapılabilir olduk ve problemleri çözebilmek için elimizde referans olay günlükleri oluşmaya başladı.

İleti bozulma işlemleri Exchange Server 2003 üzerinde de olmaktaydı ve Exchange Server 2003 üzerinde ise Archive Sink özelliği aktif duruma getirilir ve iletiyi bozan nesne tespit edilmeye çalışılırdı. Exchange Server 2007 de ise Exchange Server Pipeline Tracing olarak bu teknoloji olarak isim değiştirdi.

SMTP Gateway Güvenlik çözümlerinde çok fazla değişim oldu. Artık Exchange Server mimarisi ile uyumlu bir çok yazılım ve donanım bulunmaktadır. En ufak bir güncelleştirme ile uyumsuz duruma gelen SMTP Gateway Güvenlik ürünlerine artık hızlı çözümler bulabilmekte ve problemleri çözebilmekteyiz.

SMTP Gateway Güvenlik pazarında çok büyük gelişmeler olmuş olsa bile Exchange Server Pipeline Tracing özelliği Microsoft Exhange Server üzerinde de bulunmaktadır ve Exchange Server Kurulum işlemleri tamamlandıktan sonra varsayılan değerlerde kapalı durumda beklemektedir.

Exchange Server üzerinde bozulan bir ileti sadece SMTP Gateway güvenlik ürünleri için sınırlı değildir. Exchange Server Hub Transport Role seviyesinde bir iletiye etki eden diğer ürünlerde ileti bozulmasına neden olmaktadır.

Exchange Server Pipeline Tracing özelliği uyumsuz SMTP Gateway güvenlik ürünleri için kullanıldığı gibi mail imza programları içinde kullanılmaktadır. Exchange Server ile uyumsuz olan mail imza programları da iletilerin bozulmasına neden olabilmektedir.

3. Microsoft Exchange Server Pipeline Tracing Log Niçin Kullanılır?

Exchange Server e-posta sisteminiz de yaşamış olduğunuz bir ileti bozulma problemi bulunmakta. Bu ileti bozulma problemi de bir-iki kullanıcıda değil de bütün e-posta kullanıcılarında oluşmakta.

İleti bozulma problemi genel.

Kullanıcıların e-posta client sistemlerine odaklandınız ve bir problem bulamadınız. Kullanıcılar, e-posta gönderdikleri zaman X harfini kullanırken karşı tarafa bu Y harfi olarak değişmekte. ASCI karakter problemleri yaşıyorsunuz, ileti ekleri anlamsız ve okunmaz duruma gelmekte.

Bu durumu yaşadığınız zaman Exchange Server Pipeline Tracing Log Olay Günlüklerini aktif duruma getirmeli ve hızlıca problem analizine başlamalısınız.

4. Exchange Server Pipeline Tracing Log Olay Günlükleri Planlama

Yukarıda paylaşmış olduğum senaryoda ki gibi bir probleminiz varsa Exchange Server Pipeline Tracing Log Olay Günlükleri özelliğini açmalı ve problemi hangi e-posta sisteminin yaptığını tespit etmelisiniz.

e-postalar , exchange Server Role üzerinde mi yoksa Exchange Services özelinde mi yoksa üçüncü taraf bir SMTP gateway tarafından mı bozulmakta.

Bu analizi yapabilmek için Exchange Server Pipeline Tracing Log Olay Günlükleri özelliğini aktif duruma getirmeliyiz.

Exchange Server Pipeline Tracing Log Olay Günlükleri var sayılan değerde kapalıdır. Microsoft Exchange Server 2016 için MailboxTransportService ve TransportService özelinde iki adet Pipeline Tracing Log ayarı bulunmaktadır.

Exchange Server organizasyonu için de Pipeline Tracing Log aktif durumda mı, yapılandırılan PipelineTracingPath dizni nedir ve Pipeline Tracing Sender Address yapılandırılmış mı görmek için aşağıda ki komutları kullanabilirsiniz.

Yukarıda paylaşmış olduğum komut ile MailboxTransportService için kontrolleri sağlayabilirsiniz.

Yukarıda paylaşmış olduğum komut ile TransportService için kontrolleri sağlayabilirsiniz.

Yukarıda paylaşmış olduğum komut ile pipeline tracing özelliğini sunucu üzerinde açabilirsiniz.

Yukarıda paylaşmış olduğum komut ile pipeline tracing olay günlüklerinin oluşacak olduğu dizini değiştirebilirsiniz. Bu değişikliği dikkate almanızı ve varsayılan dizinde bırakmamanızı önermekteyim. pipeline tracing olay günlükleri var sayılan değerde kapalıdır ve barınmış olduğu dizin C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Mailbox\PipelineTracing yoludur.

Pipeline Tracing olay günlükleri çok fazla olay günlüğü oluşturduğu için varsayılan dizin de bırakılması önerilmemektedir.

#Exchange Server Logging etiketi ile Exchange Server kurulum işlemleri tamamlandıktan sonra var sayılan dizinleri değiştirmiştik. Pipeline Tracing olay günlükleri var sayılan değer de kapalı olduğu için Exchange Server Logging Dizini Değiştirme işlemlerini yapmış olduğumuz makalede ki işlemler bu ihtiyaç için kullanılamaz ve ayrıca değiştirmeniz gerekmektedir.

Yukarıda paylaşmış olduğum komut ile bir ileti bir Exchange Server üzerinden bir diğerine transfer edilirken yada Exchange Server üzerinden SMTP Gateway ürününe transfer edilirken, transfer edilme sırasında ki bir kopya imzalanmadan önce, yani değişikliğe uğramadan önce ki kopyasının gönderilecek olduğu posta kutusunu belirtebilirsiniz.

Bu özelliği Journaling kuralı ile karıştırmayalım. Journaling işlemi bir postanın kopyasını saklarken bu Pipeline Tracing Sender Address ise postanın imzalanmadan önce ki sürümünü tutmakta ve ileti transfer işlemi sonrasında uğramış olduğu değişiklikleri analiz etmek için kullanılmaktadır.

Yukarıda paylaşmış olduğum komut ile pipeline tracing özelliğini sunucu üzerinde kapatabilirsiniz.

Exchange Server Pipeline Tracing Log özelliğini aktif duruma getirdiğiniz zaman da pasif duruma getirdiğiniz zaman da yapılan değişikliklerin uygulanabilmesi için Microsoft Exchange Transport servisini yeniden başlatmanız gerekmektedir.

Yukarıda paylaşmış olduğum pipeline tracing komutları ile ileti bozulma problemlerini tespit edebilir, bir iletinin hangi transfer sürecinde bozulmaya uğradığını analiz edebilirsiniz. ileti bozulma problemlerini tespit ettikten sonra Exchange Server pipeline tracing özelliğinin kapatılması önerilmektedir.

Exchange Server pipeline tracing özelliği özel durumlar da kullanılan ve sürekli açık kaldığı zaman Exchange Server üzerinde performans problemlerine neden olan bir özelliktir ve sadece özel durumalar için kullanılmalıdır.

Bir ileti bozulma işlemi ileti transfer sürecinde bozulabildiği gibi ayrıca, son kullanıcının mail client üzerinde istemiş olduğu okundu raporu, iletildi raporu, otomatik cevap şablonları, Out Of Office cevapları da ileti bozulmalarına neden olmaktadır.

5. Bozulan bir iletiyi bulma adımları

Exchange Server Pipeline Tracing Log mimarisi Microsoft Exchange Server Message Tracking Mimari ‘sini beslemekte olup bozulan bir iletiyi tespit etmemizi kolay duruma getirmektedir.

Bu senaryo içinde bozulan bir iletiyi nasıl bulduğumuzu sizlere paylaşacağız.

Öncelikli olarak sahip olduğumuz Exchange Organizasyon mimarisinden sizlere bilgi vermek istiyorum. Office 365 Hybrid mimarisi bulunmakta. Yerel veri merkezi içinde bulunan Exchange Server ile Office 365 Exchange Online Sunucuları ile birlikte çalışmakta.

Aynı organizasyon mimarisi onprem mailbox ve online mailbox olarak hibrit alt yapı bulunmakta. yaşamış olduğumuz problem ise aşağıda özetliyorum.

• Yerel veri merkezi içinde bulunan Onprem Mailbox ‘lar dış dünyaya ve Exchange Online Mailbox ‘lara e-posta gönderebilmekte ve alabilmekte. bir problem bulunmamakta.
• Exchange Online Mailbox ‘lar ise dış dünyaya ileti gönderebilmekte ve alabilmekte fakat Exchange Online üzerinde bulunan mailbox ‘lar Onprem Mailbox ‘lara posta gönderdikleri zaman iletiler onprem mailbox ‘lara gelmemekte.

Yukaruda paylaşmış olduğum ekran görüntüsü Office 365 admin center üzerinde bulunan Message trace bölümünden alındı.

• Onl-MB kullanıcısı Exchange Online üzerinde
• Onp-MB kullanıcısı yerel Exchange Server üzerinde.

Onl-MB ‘nin göndermiş olduğu iletiler Onp-MB kullanıcısına ulaşmıyor. Fakat Office 365 üzerinde Message trace araması yaptığımız zaman ise Message trace çıktıları gönderilen iletinin yerel Exchange Server tarafından kabul edildiğini bizlere söylemekte.

Yerel Exchange Sunucumuzun hemen önünde ileti güvenliğini sağlayan bir adet SMTP Gateway ürünümüz bulunmakta. Exchange Online üzerinden gönderilen ileti Exchange Server ‘a gönderilmeden önce SMTP Gateway güvenlik ürünümüz üzerinden geçiyor, gerekli denetimler yapılıyor ve gönderilen ileti burada da Exchange Server ‘a bırakıldığını görebiliyoruz.

Fakat, gönderilen ileti kullanıcı posta kutusuna ulaşmadı.

Burada derin analiz yapmamız gerekmekte ve Exchange Server üzerinde Pipeline Tracing Log özelliğini aktif duruma getirmemiz gerekmekte. Sonra ki adım ise SMTP Gateway üzerinde bulunan message queue ID ‘sini bir kenara not ediyoruz.  Bozulan iletiyi bulabilmemiz için bu message queue ID ‘si bizlere lazım olacak.

SMTP Gateway üzerinde bulunan bu message queue ID ‘si Exchange Server tarafından oluşmakta ve SMTP Gateway ‘a bu ID üzerinden göndermiş olduğun iletiyi kabul ettim demektedir.

message queue ID ‘sini de öğrendikten sonra şimdi ise iletinin göndermiş olduğu zaman diliminde üretilen Microsoft Exchange Server Message Tracking olay günlüklerinde arama yapmamız gerekmektedir.

İlgili Message Tracking olay günlüğünü bulduğumuz zaman bozulan iletinin neden bozulduğunu bilmemiz çok daha kolay olacak. iletinin gönderilmiş olduğu zaman diliminde üretilen Message Tracking olay günlüğünü açıyoruz, SMTP Gateway üzerinde bulunan message queue ID ‘sini aramaya başlıyoruz.

iletinin gönderilmiş olduğu zaman diliminde üretilen Message Tracking olay günlüğünü açıp, SMTP Gateway üzerinde bulunan message queue ID ‘sini yazıyoruz ve iletinin neden bozulduğunu görebiliyoruz.

Exchange Server üzerinde oluşturmuş olduğumuz bir transport rules Exchange Online üzerinden gönderilen iletilerin Exchange Onprem Mailbox ‘a gelmesini engellemekte ve silmekte.

Message Tracking olay günlüğünde gördüğümüz gibi “Message deleted by the transport rules agent” açıklaması bulunmakta.

Office 365 Message Tracking olay günlüklerinde, SMTP Gateway Message Tracking ve ileti olay günlüklerinde bu türde ki teslim edilmeyen iletiyi bulamayız. Nedeni basit, ileti trafiğinde bir engel bulunmamakta, ileti sağlıklı bir şekilde transfer sürecini tamamlamakta fakat bizlerin yazmış olduğu bir kural, yada Exchange Server üzerinde bulunan bir DLP ajanı iletinin içeriğini bozmakta ve kullanıcı posta kutusuna teslim etmemekte.