Exchange mail sorunları nasıl incelenir?

Exchange mail sorunları nasıl incelenir?

Exchange mail sorunlarında önce olayın posta akışı, erişim, izin veya istemci tarafında nasıl göründüğü belirlenmelidir. Bir iletinin geri dönmesiyle yerel sunucuda beklemesi aynı bulgu değildir. Gönderici, alıcı, olay zamanı ve hata bildirimi incelemenin başlangıç verilerini oluşturur. Sonuç değerlendirilirken yapılan değişiklikle kullanıcıların beklediği iş akışının düzelmesi ayrı kontrol edilmelidir. Uygulama kapsamı için Exchange mail hizmeti sayfasındaki açıklamalar da değerlendirilebilir.

Talebiniz tek bir olaya müdahale, tekrar eden sorunun araştırılması veya mevcut Exchange ortamının düzenli destekle devralınması olabilir. Her ihtiyaç aynı teslimi oluşturmaz. İlk görüşmede sorunun kimleri etkilediği, ne zaman başladığı ve işletmenin hangi işini durdurduğu anlaşılmalıdır. Uygulama yolu ve bedel bu bilgilerle netleştirilir; üretici, internet sağlayıcısı veya başka bir ekibe bağlı sonuçlar için incelemeden kesin çözüm saati vaat edilmez.

İlk kapsamı olayın yönüne ve etkisine göre belirleyin

Exchange sorunlarında “mail gitmiyor” ifadesi tek başına hangi hizmetin alınacağını anlatmaz. Şirket içi iletilerin çalışıp dış gönderimin durması, yalnız tek alıcıya hata alınması veya bütün kullanıcıların kutuya erişememesi farklı incelemelerdir. Destek talebinizde bu ayrımı açıklamanız başlangıç değerlendirmesini kolaylaştırır. Sorunun hangi cihaz ve uygulamalarda görüldüğü de olayın sınırını belirlemeye yardımcı olur.

Destek kapsamında etkilenen kullanıcı grubu, iş etkisi, ilk görülen zaman ve yakın dönemde yapılan değişiklikler kayda alınabilir. Örneğin sertifika yenilenmesi ya da ağ değişikliği olayla aynı zamana denk gelmiş olabilir; bu bilgi tek başına nedenin bulunduğunu kanıtlamaz. Teknik inceleme mevcut bulguları karşılaştırmalıdır. İşletme, kritik iş akışını ve alternatif çalışma imkanını bildirirse talebin önceliği somut etkiye göre görüşülebilir. Kullanıcı sayısı tek başına öncelik ölçütü olmamalıdır.

Geri dönen iletinin teknik bildirimini inceleyelim

Teslim edilemedi bildirimi veya NDR, iletinin neden ulaşmadığını araştırmak için önemli bir girdidir. Microsoft, bu bildirimlerde hata kodu ve yöneticiler için teknik ayrıntı bulunabildiğini açıklar. Aynı “geri döndü” ifadesinin altında yanlış alıcı adresi, karşı tarafın yanıtı veya farklı posta akışı nedenleri olabilir. Destek talebinde bildirimin tam teknik kısmını ve örnek olay zamanını paylaşmanız yararlıdır.

Gizli ileti içeriğini gereksiz biçimde göndermeniz gerekmez; inceleme için gerekli alanlar yetkili yöntemle alınabilir. Hata kodunu görmeden genel bir DNS düzeltmesi uygulamak veya her alıcıyı filtre dışına çıkarmak doğru başlangıç değildir. Destek çalışmasında bildirimin hangi sistemden geldiği ve önerilen müdahalenin kimin sorumluluğunda olduğu belirlenir. Sonuç, yalnız kodun anlamının açıklanmasıyla sınırlı kalmamalı; uygulanabilir sonraki adım ve açık bağımlılıklar işletmeye bildirilmelidir.

Exchange Online ileti izleme bulgularını kullanalım

Exchange Online ortamında ileti izleme, hizmetin iletiyi alıp almadığını ve süreçte hangi durumların görüldüğünü incelemek için kullanılabilir. Microsoft'un belgesinde alınma, reddedilme, ertelenme veya teslim gibi durumların araştırılabildiği belirtilir. Bu işlem gerekli yönetim izinleriyle yapılır. İnceleme talebinde gönderici, alıcı ve zaman aralığının belirli olması, aranan olayın bulunmasına yardımcı olur.

İzleme sonucu teknik bir bulgudur; alıcının iletiyi okuduğunun veya işletmenin istediği klasörde gördüğünün tek başına kanıtı değildir. Teknik ekip, elde edilen sonucu ilgili senaryoyla ilişkilendirmelidir. Dış alıcı sisteminde araştırılacak bir durum varsa hangi bilginin karşı ekibe iletileceği açıklanabilir. Bu hizmetin teslimi, yalnız panel ekran görüntüsü göndermek yerine olayın ulaşılan aşamasını ve bundan sonra yapılacak işi anlaşılır biçimde belirtmek olmalıdır. Platformun kayıt ve erişim sınırları ayrıca dikkate alınır.

Yerel Exchange kuyruğunda bekleyen iletileri değerlendirelim

Yerel Exchange Server ortamında kuyruklar, iletilerin işlenme veya teslim aşamasında geçici olarak beklediği alanlardır. Kuyrukta ileti görülmesi tek başına bütün sunucunun bozuk olduğunu göstermez. Bekleme nedeni, etkilenen hedefler ve olayın ne zamandır sürdüğü incelenmelidir. Bu çalışma Online ileti izlemeyle aynı yönetim ekranı veya aynı erişim modeli olarak ele alınmamalıdır.

Destek talebinde sunucunun sürümü, bilinen hata ve son değişiklikler paylaşılabilir. Yetkili inceleme sonucunda ağ, hedef sistem, taşıma yolu veya ilgili servis bağımlılıklarının hangi ölçüde araştırılacağı belirlenir. Kuyruğu temizlemek veya sunucuyu yeniden başlatmak gibi değişiklikler, olay anlaşılmadan otomatik çözüm olarak sunulmaz. İşletmenin iletileri ve mevcut kayıtları korunarak kontrollü müdahale planlanmalıdır. Teslim raporunda bekleyen trafiğin durumu, uygulanan işlem ve doğrulanabilen sonuç ayrı açıklanır.

Ortak kutu sorununda okuma ve gönderme yetkisini ayırın

Kullanıcının ortak posta kutusunu açabilmesi, o adres adına gönderim izni bulunduğu anlamına gelmez. Exchange Online'da tam erişim, Send As ve Send on behalf farklı izinlerdir. Bu nedenle destek olayı yalnız “kutuyu görüyor” sonucuyla kapatılmamalıdır. İşletmenin istediği davranış anlaşılmalı ve mevcut yetkiler bu kararla karşılaştırılmalıdır. Başka bir kullanıcının verisine erişim için yetkili şirket onayı alınmalıdır.

Örnek bir talepte satış çalışanı kutuyu okuyabiliyor, ancak yanıtta kendi adresi görünüyor olabilir. Bunun kullanıcı tercihi, istemci davranışı veya izin düzeniyle ilişkisi incelenir. Teknik ekip hangi iznin değiştiğini ve hangi örnek gönderimle kontrol edildiğini kaydeder. Gereksiz geniş erişim vermek kısa yol olarak kullanılmamalıdır. Destek hizmetinin kapsamı, onaylanmış görevi doğru yetkiyle çalışır hale getirmek ve sonucu doğrulamak şeklinde tanımlanmalıdır; şirketin erişim kararını teknik ekibin kendiliğinden vermesi beklenmemelidir.

Sunucu, sertifika ve dizin bağımlılıklarını kapsamlandıralım

Yerel Exchange desteğinde sorunun kaynağı yalnız Exchange uygulaması içinde olmayabilir. Sunucu altyapısı, ağ, sertifika veya dizin hizmetleri incelemeye dahil olabilir. Hangi sistemlere erişim bulunduğu ve hangi ekiplerin sorumlu olduğu başlangıçta anlaşılmalıdır. Örneğin ağ erişimi başka bir sağlayıcı tarafından yönetiliyorsa teknik bulguların o ekibe aktarılması ve sonucun yeniden kontrol edilmesi gerekebilir.

Teklifte Exchange incelemesiyle işletim sistemi, depolama veya ağ düzeltmelerinin aynı bedelde olup olmadığı belirtilmelidir. Kapsam dışı bir bağımlılık ortaya çıkması, araştırmanın gereksiz yapıldığı anlamına gelmez; yeni işin onay süreci ayrıca işletilmelidir. Güvenli başlangıç için mevcut sürüm, erişim sorumluları ve mümkünse sistem notları hazırlanabilir. İnceleme sırasında kullanılacak yetkiler işin gereğine göre sınırlandırılır. Üretim ortamında değişiklik gerekiyorsa iş etkisi, onay ve kontrol adımları müşteriye açıklanmalıdır.

Destek sonu olan sürümlerde kalıcı planı ayrıca ele alın

Mevcut sürümün destek durumu, olay müdahalesinden bağımsız olarak dikkate alınmalıdır. Microsoft'un güncel destek matrisine göre Exchange 2016 ve 2019 desteği 14 Ekim 2025'te sona ermiştir. Bir teknik sorunun giderilmesi bu sürümlerin yeniden desteklenen ürün haline geldiği anlamına gelmez. Subscription Edition ve diğer hedef seçenekler, lisans ve altyapı koşullarıyla ayrıca değerlendirilmelidir.

İlk destek ihtiyacı çalışan hizmetin incelenmesi olabilir; kalıcı sürüm geçişi ise ayrı proje gerektirebilir. Teklifte bu iki iş birbirine karıştırılmamalıdır. Olay sırasında yapılan işlem, açık kalan riskler ve sonraki proje ihtiyacı raporlanabilir. İşletme böylece yalnız mevcut hatanın sonucunu değil, hangi kararın beklediğini de görür. Eski bir ortama destek talep ettiğinizde sürüm ve derleme bilgisini paylaşmanız önemlidir. Uygun geçiş yolu incelenmeden tek adımda güncelleme veya kesintisiz dönüşüm vaat edilmez.

Müdahale sonrası kabulü aynı olayla doğrulayalım

Destek çalışmasının kapanışında başlangıçtaki sorun senaryosu yeniden denenmelidir. Dış gönderim için belirlenen örnek alıcıya test, ortak kutu için doğru gönderici davranışı veya erişim sorunu için etkilenen kullanıcının işlemi kontrol edilebilir. Bir ayarın kaydedilmesi ile iş akışının düzelmesi ayrı sonuçlardır. Kontrolün hangi kullanıcı, uygulama ve zaman aralığında yapıldığı kayda alınmalıdır.

Talep tamamen giderilemediyse bunun nedeni ve sonraki sorumlu açık gösterilir. Karşı alıcı sistemi, üretici incelemesi veya müşteriden beklenen erişim gibi bağımlılıklar ayrıca yazılabilir. Geçici çalışma yöntemi uygulandıysa kalıcı çözümden ayrı belirtilmelidir. Hizmet raporu yapılan değişikliği ve açık kalan işi birlikte sunmalıdır. Bu yaklaşım işletmenin talebin durumunu anlayabilmesini sağlar; yalnız “kontrol edildi” şeklindeki kısa bir mesajla belirsiz kapanış yapılmasını önler. Kabul yöntemi destek kapsamı görüşülürken belirlenebilir.

Exchange mail destek hizmeti fiyatı ve devir kapsamı

Exchange mail destek hizmeti fiyatı; tek olay veya düzenli destek modeli, Online ya da yerel ortam, sunucu ve kullanıcı sayısı, sorunun yaygınlığı ve gerekli inceleme kapsamıyla belirlenir. Yerinde çalışma, çalışma saati dışında müdahale veya başka sistemlerde ek düzenleme gerekiyorsa bunlar teklifte ayrıca açıklanır. Sabit bir ücret veya doğrulanmamış başlangıç fiyatı vermek yerine mevcut ihtiyaç üzerinden kapsam görüşülür.

Düzenli destek için ortamın devralınması da emek gerektirebilir. Mevcut kayıtların kontrolü, erişimlerin doğrulanması, açık olayların listelenmesi ve sorumluların belirlenmesi başlangıç teslimleri olabilir. Yanıt, inceleme ve çözüm hedefleri aynı şey değildir; sözleşmedeki ifadeler hangi aşamayı kapsadığını göstermelidir. Belirli bir yanıt süresi veya kesintisizlik oranı ancak doğrulanmış ticari koşullarla sunulabilir. İşletmeniz yalnız olay incelemesi istiyorsa gelecekteki sınırsız destek veya sürüm projesinin aynı bedelde olduğu varsayılmamalıdır.

Uygulama öncesi son kontroller

Destek talebinizde mevcut ortamı, etkilenen kullanıcıları, olayın başlangıcını ve alınan hata bildirimini belirtin. Yerel sunucuda biliniyorsa sürüm ve son yapılan değişiklikleri ekleyin. Önceki sağlayıcının açık kaydı veya ilgili teknik bulgusu varsa paylaşılması tekrarlı incelemeyi azaltabilir. Hangi iş akışının aksadığını anlatmanız önceliğin değerlendirilmesine yardımcı olur. Gizli parolalar ve doğrulama kodları başvuru formuna yazılmamalıdır.

Son kontrol listesinde hata bildirimi, olay zamanı, ileti izleme veya kuyruk bulguları, erişim izinleri ve sonuç testleri birlikte yer almalıdır. Tamamlanan kontrolleri ve açık kalan işleri ayrı kaydedin. Sorumluları ve sonraki adımları belirlemek, uygulama sonucunu başlangıçta tanımlanan kapsamla karşılaştırmayı kolaylaştırır.

Teklif için Exchange mail hizmeti sayfasına gidin.

Sık Sorulan Sorular