Exchange Online'da Get-MessageTrace'ın emekliye ayrılması PowerShell yöneticilerini V2 cmdlet'lerine yönlendiriyor

Microsoft eski Message Trace araçlarını emekliye ayırıyor

Microsoft, Exchange Online'daki eski Message Trace deneyimini kapatmaya başladı; bu hem Exchange Admin Center'daki eski arayüzü hem de Get-MessageTrace ve Get-MessageTraceDetail PowerShell cmdlet'lerini kapsıyor. dev.to'da yayımlanan bir geçiş kılavuzuna göre, yerini alacak olan Get-MessageTraceV2 ve Get-MessageTraceDetailV2 halihazırda genel kullanıma sunulmuş durumda.

Makalenin Microsoft'un Message Center bildirimi MC1092458'ye dayandırdığı zaman çizelgesi iki eşik içeriyor. Eski EAC arayüzünün ve eski cmdlet'lerin kullanımdan kaldırılması 1 Eylül 2025'te başladı. Eski entegrasyonların bel bağladığı Reporting Web Service'in Message Trace verisi desteği ise 18 Mart 2026'dan itibaren kaldırılacak. Get-MessageTrace'ı çağırmaya devam eden betikler bir geçiş süresi boyunca çalışmaya devam edecek, ancak dev.to yazısı nihai kapanma için bir tarih vermiyor ve merkezindeki uyarı açık: cmdlet çalışmayı bırakana kadar bekleyen yöneticiler, betiğin en çok ihtiyaç duyulduğu anda, canlı bir e-posta teslim olayı sırasında kopukluğu fark edecek.

Yeni deneyim Aralık 2024'te genel önizlemeye girdi ve EAC'de Mail flow > Message Trace altında genel kullanıma ulaştı. Petri'ye atıf yapan makale, modernize edilmiş bir arayüz, "Quarantined" ve "Filtered as spam" gibi daha ince teslim durumu filtreleri, hesap başına özelleştirilebilir sütunlar ve yöneticinin yapılandırdığı saat dilimini izleyen zaman damgaları listeliyor.

V2 cmdlet'leri nasıl farklı davranıyor

Yeni sözdizimi eskisini andırıyor, ancak Microsoft'un belgeleri, dev.to'da özetlendiği şekliyle birkaç davranışsal değişiklikten bahsediyor:

• -Page veya -PageSize yok. V2 cmdlet'i sayfalı veri çekmeyi bırakıyor. Bir sonuç sınırının ötesine geçmek için betik, -StartingRecipientAddress parametresini -EndDate ile birlikte kullanıyor; önceki sorgunun son kaydından alıcı adresini ve alınma zamanını alıyor.
• Doksan günlük geçmiş, sorgu başına on gün. Yeni deneyim 90 güne kadar geriye dönük arama yapabiliyor, ancak tek bir çağrı 10 günlük bir aralıkla sınırlı; bu yüzden daha geniş aralıklar parçalara bölünmeli.
• Daha yalın, daha hedefli sorgular. Microsoft, dönen hacmi sınırlamak için -ResultSize kullanmayı, başlangıç ve bitiş tarihlerini daraltmayı, -SenderAddress ile filtrelemeyi ve mümkün olduğunda -MessageTraceId kullanmayı öneriyor. İzleme kimliği aslında 1.000'den fazla alıcıya gönderilen iletiler için zorunlu.
• UTC çıktısı. Arayüzün aksine cmdlet, zaman damgalarını UTC olarak döndürüyor; bu yüzden yerel saatlerle karşılaştırma yapan betiklerin dönüştürme mantığına ihtiyacı var.

Tek bir iletiyi uçtan uca izlemek için belgelenen yöntem, eski Get-MessageTraceDetail çağrısını bir pipeline ile değiştiriyor: Get-MessageTraceV2'yi bir -MessageTraceId ile çalıştırın, sonra sonucu Get-MessageTraceDetailV2'ye yöneltin. Bu, alındı, teslim edildi, gecikti, engellendi, karantinada gibi olay başına ayrıntılı durumları, eski araçların sunduğundan daha hassas bir şekilde ortaya koyuyor.

Zamanlanmış otomasyonun taşınması

Teslim raporları, e-posta SLA metrikleri veya bounce uyarıları üreten zamanlanmış görevleri, Azure Automation runbook'ları veya izleme işleri olan yöneticiler, makaleden pratik bir kontrol listesi alıyor:

• Eski cmdlet'lere yapılan başvurular için betik deposunu tarayın; örneğin .ps1 dosyaları arasında Select-String ile Get-MessageTrace ve Get-MessageTraceDetail araması yapın.

• Çağrıları V2 cmdlet'leriyle değiştirin, -Page ve -PageSize parametrelerini kaldırın ve sonuç hacmi yüksek olan yerlerde -StartingRecipientAddress ve -EndDate üzerine kurulu döngüler ekleyin.

• Tüm geçmişi sorgulamadan önce birkaç saatlik bir pencereyle test edin ve çağrı başına 10 günlük sınırı göz önünde bulundurun.

• V2 çıktısı UTC olduğu için saat dilimi işlemeyi doğrulayın.

Yazar ayrıca geçişi bir denetim fırsatı olarak değerlendirmeyi öneriyor: her raporun veya uyarının hâlâ gerekli olup olmadığını kontrol edin ve yeni durum ayrımlarının — örneğin "Filtered as spam" ile "Quarantined" ayrımının — posta akışı raporlamasını daha kullanışlı hale getirip getirmeyeceğini değerlendirin.

Neden önemli

Posta akışı teşhis betikleri genellikle bir kez yazılır ve yalnızca bir şeyler bozulduğunda elden geçirilir. Bir olayın ortasında ortaya çıkan bir kullanımdan kaldırma, yöneticileri asıl araştırma araçlarından, tam da ihtiyaç duyulan anda mahrum bırakıyor. Geçiş çabasının kendisi büyük değil — çoğunlukla bir yeniden adlandırma artı sayfalama ve saat dilimi ayarlamaları — ancak eksik sayfa parametreleri, sorgu başına 10 günlük sınır ve toplu postalarda zorunlu izleme kimliği gibi anlamsal farklılıklar, saf bir bul-değiştir yaklaşımını başarısız kılacak. Eski cmdlet'ler Eylül 2025'ten beri kullanımdan kaldırılma sürecindeyken ve Reporting Web Service desteği 18 Mart 2026'dan itibaren kapanırken, otomasyonlarını henüz envanterine katmamış ekipler, olay müdahalelerini tarihsiz bir ön süre üzerine oynuyor.