Tüm yazılarMicrosoft Security

Defender for Endpoint 'Sensor Inactive' Sorununun Çözümü (2026)

·~7 dk okuma
Microsoft Defender for Endpoint sensor health durumu — Microsoft Security blog resmi görseli

Özet (TL;DR): Microsoft Defender for Endpoint (MDE) portalında bir cihaz Inactive, Impaired communications veya No sensor data olarak görünüyorsa cihaz son 7 gündür Defender servisine sinyal göndermiyor ya da kısıtlı iletişim kuruyor demektir. Çözüm sırası: önce cihazın gerçekten kullanımda olup olmadığını doğrulayın, sonra internet/proxy bağlantısını ve WinHTTP yapılandırmasını kontrol edin, ardından Defender service URL'lerine erişimi test edip son olarak MDE Client Analyzer (MDECA) ile detaylı tanılama çalıştırın. Adım adım yapılandığında vakaların büyük çoğunluğu support ticket açmadan çözülür.

Hata Belirtisi: Defender portalında ne görüyorsunuz?

Microsoft Defender portalı security.microsoft.com içinde Reports > Device health and compliance > Sensor health & OS sayfasında veya Assets > Devices cihaz envanterinde sensor health durumu dört kategoriye ayrılır:

  • Active — Cihaz aktif olarak Defender for Endpoint servisine veri raporluyor. İdeal durum.
  • Inactive — Cihaz son 7 günden uzun süredir Defender for Endpoint servisine sinyal göndermiyor. Cihaz kapalı, yeniden kurulmuş, off-board edilmiş veya bağlantı kopmuş olabilir.
  • Impaired communications — Cihazla iletişim kısıtlı. Deep analysis için dosya gönderme, dosya blokajı, cihaz izolasyonu gibi servis-cihaz iletişimi gerektiren işlemler çalışmayabilir.
  • No sensor data — Cihaz servisle iletişim kuruyor ama sadece kısmi sensör verisi gönderebiliyor. Sınırlı sayıda alert tetiklenebilir.

Portaldaki Device health kartında Misconfigured ve Inactive rakamları organizasyonunuzun risk fotoğrafıdır. Her iki sayıyı toplam endpoint sayısının %1'inin altında tutmak hedeftir; %5'i aşıyorsa sistematik bir yapılandırma sorunu vardır.

Kök Neden Analizi: Inactive sebepleri

Microsoft'un resmi dokümantasyonuna göre bir cihazın Inactive durumuna düşmesinin dört yaygın nedeni vardır:

1) Cihaz fiilen kullanımda değil

7 günden uzun süredir açılmayan veya internete bağlanmayan her cihaz Inactive kategorisine düşer. Tatil dönüşü, uzun süre çalınmayan stok cihazları, depodaki yedek dizüstüler bu kategoriye girer. Çözüm: cihazı en az 30 dakika açık ve internete bağlı tutun; Inactive durumu otomatik temizlenecektir.

2) Cihaz yeniden kuruldu veya adı değiştirildi

Bir cihaz yeniden kurulduğunda veya Rename-Computer ile adı değiştirildiğinde Microsoft Defender XDR yeni bir cihaz nesnesi (device entity) oluşturur. Eski kayıt envanterde Inactive olarak kalır. Bu beklenen davranıştır. Çözüm: yeni cihaz adıyla arayıp aktif raporlama yaptığını doğrulayın, eski kayıt 30 gün sonra otomatik arşivlenir.

3) Cihaz off-board edildi

Off-boarding paketi çalıştırıldıktan sonra cihaz portalda görünmeye devam eder. 7 gün sonra durum Inactive olarak güncellenir. Eğer yanlışlıkla off-board ettiyseniz onboarding paketini yeniden çalıştırarak cihazı tekrar kaydedebilirsiniz. Microsoft Security kapsamında onboarding/off-boarding yönetimini merkezi olarak Intune veya Group Policy üzerinden planlamak öneririz.

4) Cihaz sinyal göndermiyor

En kritik kategori budur: cihaz açık ve internete bağlı, ama Defender servisine herhangi bir kanal üzerinden veri akıtmıyor. Bu durumda Misconfigured sınıflandırması da başlatılır. Sebep genellikle proxy/firewall/WinHTTP yapılandırması veya servis URL'lerine erişim engelidir.

Impaired Communications ve No Sensor Data Ayrımı

Impaired communications — Cihaz Defender'a temel telemetri gönderebiliyor ama bidireksiyonel iletişim kanalı zayıf. Bu durumda response action'lar (isolate device, run AV scan, collect investigation package, deep analysis) gecikir veya başarısız olur. Genellikle outbound TCP 443 trafiğine kısıtlama veya proxy authentication sorunu kök nedendir.

No sensor data — Cihaz Defender'a heartbeat gönderiyor ama yapısal telemetri (process events, network connections, file modifications) eksik. Bu durumda EDR alert üretimi ciddi şekilde azalır. Tipik sebepler: Windows Diagnostic Data servisi kapalı, Microsoft Defender Antivirus politika ile devre dışı, ELAM (Early Launch Antimalware) driver yüklenmemiş.

Adım Adım Çözüm: En kolaydan en zora

Adım 1 — Cihazın yaşam belirtisini doğrulayın

Cihaza fiziksel veya uzaktan (RDP, AVD, Windows 365 Cloud PC) erişin. Sistem saatinin doğru olduğunu kontrol edin — saat 5 dakikadan fazla sapmışsa TLS handshake hataları Defender bağlantısını engeller. w32tm /resync ile saati yeniden senkronlayın.

Adım 2 — Defender Antivirus servis durumunu kontrol edin

PowerShell'i yönetici olarak açın ve şu komutu çalıştırın:

Get-MpComputerStatus | Select AntivirusEnabled, AntispywareEnabled, RealTimeProtectionEnabled, AMServiceEnabled, AMRunningMode

Dört değer de True ve AMRunningMode Normal ya da Passive Mode olmalı. EDR Block Mode veya Disabled görüyorsanız üçüncü taraf AV ürünü Defender'ı pasifleştiriyor demektir; ELAM driver'ın yüklü olduğunu doğrulayın.

Adım 3 — Cihaz Defender for Endpoint'e onboard durumunu kontrol edin

Registry yolunu kontrol edin: HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status. OnboardingState değeri 1 olmalı. 0 ise cihaz hiç onboard edilmemiş demektir; Intune'dan EDR profilini cihaza atayın veya manuel onboarding script'i çalıştırın.

Adım 4 — Internet bağlantısı ve WinHTTP doğrulaması

MDE sensor Microsoft Windows HTTP (WinHTTP) üzerinden raporlama yapar — WinINET değil. Önemli ayrım: kullanıcı tarayıcısı internete çıkabilir ama WinHTTP proxy yapılandırması eksikse Defender sensor sinyal gönderemez.

WinHTTP proxy ayarını kontrol edin:

netsh winhttp show proxy

Eğer ortamınızda explicit proxy varsa cihaza WinHTTP proxy'sini de tanımlayın:

netsh winhttp set proxy proxy-server="http://proxy.firma.local:8080" bypass-list="<local>"

Adım 5 — Defender service URL'lerine erişimi test edin

Microsoft Defender for Endpoint cihazlarının erişmesi gereken URL listesi learn.microsoft.com üzerinde "Microsoft Defender for Endpoint connectivity requirements" sayfasında yayımlanır. Test için Microsoft'un sağladığı MDEClientAnalyzer aracını kullanın veya kritik URL'leri tek tek Test-NetConnection ile sınayın. Outbound TCP 443 trafiği *.endpoint.security.microsoft.com, *.events.data.microsoft.com, *.blob.core.windows.net domainlerine açık olmalı.

Adım 6 — Diagnostic Data servisini doğrulayın

Defender for Endpoint Connected User Experiences and Telemetry (DiagTrack) servisine bağımlıdır. Servisi kontrol edin:

Get-Service -Name DiagTrack | Select Status, StartType

Status Running, StartType Automatic olmalı. GPO ile devre dışı bırakılmışsa Computer Configuration > Administrative Templates > Windows Components > Data Collection and Preview Builds > Allow Diagnostic Data politikasını Required (Security) veya üstüne ayarlayın.

Adım 7 — Sensor servislerini yeniden başlatın

İlgili dört Windows servisini sırayla yeniden başlatın:

  1. Restart-Service -Name Sense -Force (Microsoft Defender for Endpoint Service)
  2. Restart-Service -Name WinDefend -Force (Microsoft Defender Antivirus Service)
  3. Restart-Service -Name MsSense -Force (varsa, EDR sensor)
  4. Restart-Service -Name DiagTrack -Force

Yeniden başlattıktan sonra 15-30 dakika bekleyin ve portalda durumu yeniden kontrol edin.

MDE Client Analyzer (MDECA) ile Derinlemesine Tanılama

Yukarıdaki adımlar sorunu çözmediyse Microsoft Defender for Endpoint Client Analyzer (MDECA) aracını çalıştırın. Bu Microsoft'un resmi tanılama aracıdır ve Windows, Linux, macOS endpoint'lerde sensor health, connectivity, event log ve policy uyumluluğunu detaylı raporlar.

MDECA çalıştırma adımları:

  1. Aracı Microsoft Learn'deki resmi linkten indirin: aka.ms/MDEAnalyzer.
  2. ZIP'i hedef cihaza kopyalayın, yönetici olarak MDEClientAnalyzer.cmd çalıştırın. L parametresiyle 5 dakikalık trace toplayabilirsiniz.
  3. Çıkan ZIP raporu inceleyin: MDEClientAnalyzerResult.htm içinde tüm bulgular kategori bazında listelenir (kırmızı = kritik, sarı = uyarı).
  4. Rapor Cloud Service Check, Telemetry Service Status, Windows Defender ATP Service, Proxy Configuration, SSL Inspection başlıklarını içerir.

MDECA çıktısı bir Microsoft destek ticket'ında zorunlu ek olarak istenir; ön cephede paylaşmaya hazır olun.

Önleyici Kontroller: Tekrar yaşanmaması için

  • Intune EDR Policy ile onboarding paketini merkezi olarak dağıtın; manuel script kullanmayın.
  • Defender for Endpoint Connectivity Checks KQL sorgularını Sentinel/Defender XDR Advanced Hunting'de saatlik çalıştırın.
  • Conditional Access politikasına "Compliant device" şartı ekleyerek inactive cihazların kritik kaynaklara erişimini engelleyin. Conditional Access politikası nasıl yapılandırılır yazımızı inceleyebilirsiniz.
  • SSL inspection / TLS interception yapan firewall/proxy ürünleri Defender trafiğini bozar. Microsoft URL listesini SSL inspection'dan muaf tutun.
  • Sensor health kart eşiklerini IT operasyon SLA'nıza dahil edin: Inactive > %3 alarm yaratsın.

Benzer Sorunlardan Ayırma

Defender for Endpoint sensor sorunlarını başka yakın görünümlü sorunlarla karıştırmamak için:

  • Defender Antivirus signature out-of-date ≠ sensor inactive. İlki signatür güncellemesi sorunu; sensor health raporu üzerinden değil Microsoft Defender Antivirus health tab'ından yönetilir.
  • Intune compliance non-compliant ≠ Defender inactive. Intune cihazı non-compliant gösterip Defender hâlâ active raporlayabilir. Intune non-compliant cihaz çözümü yazımıza bakın.
  • Entra device registration kaybı ≠ MDE sensor inactive. Cihaz Microsoft 365 içinde Entra registration kaybetse de Defender raporlamaya devam edebilir.

Sıkça Sorulan Sorular (SSS)

Microsoft Defender for Endpoint cihazı kaç gün sinyal göndermezse Inactive olur?

Resmi eşik 7 gündür. Bir cihaz son 7 gün içinde herhangi bir Defender kanalına sinyal göndermediyse durumu Inactive olarak işaretlenir. Bu süre yapılandırılabilir değildir; Microsoft tarafından sabittir.

Inactive cihazları nasıl silebilirim?

Defender XDR portalı şu anda Inactive cihazları manuel silmeye izin vermez. 30 günden uzun süre Inactive kalan cihazlar otomatik olarak envanterden gizlenir ama tamamen silinmez. Off-boarding script'i çalıştırıldığında cihaz Defender backend'inden de temizlenir. Manuel toplu temizlik için Microsoft Graph Security API üzerinden machines endpoint'i kullanılabilir.

Impaired communications sorunu firewall mı proxy mi yüzünden olur?

İkisi de olabilir. Pratik bir test: netsh winhttp show proxy komutu boş dönüyor ama tarayıcı internete çıkıyorsa WinHTTP proxy yapılandırması eksik demektir (en yaygın sebep). Eğer WinHTTP proxy doğru ama hâlâ impaired ise, firewall'da SSL inspection veya outbound 443 kısıtlaması olma ihtimali yüksektir. MDECA aracı her iki katmanı da test eder.

macOS ve Linux cihazlarda Inactive sorunu nasıl çözülür?

Mantık aynıdır ama araçlar farklıdır. macOS için mdatp health komutuyla sensor durumunu kontrol edin; Linux için mdatp health aynı şekilde çalışır. MDECA macOS ve Linux için de sürüm yayımlamıştır. Önemli not: macOS cihazları 48 saatten uzun süre uyku modunda kalırsa Cyber kanalı veri göndermez ama Command-and-Control kanalı aktif kalır; iş gününde cihaz açıldığında otomatik active duruma döner.

Sensor inactive sorunu Microsoft Defender XDR uyarısı yaratır mı?

Doğrudan bir XDR alert'i yaratmaz; sadece Device health raporunda gösterilir. Ancak organizasyonel risk yarattığı için Microsoft Defender XDR Exposure Management dashboard'unda "Devices with impaired sensor health" recommendation olarak listelenir ve Secure Score'a etki eder. Sentinel kullanıyorsanız DeviceInfo tablosu üzerinden SensorHealthState alanını sorgulayan KQL analytic rule yazabilirsiniz.

Conditional Access ile inactive cihazları engellersem kullanıcılar erişim kaybeder mi?

Evet — eğer cihaz gerçekten kullanılmıyorsa zaten erişim girişimi olmaz. Ama cihaz aktif ama sensor inactive raporluyorsa kullanıcı erişimini kaybeder. Bu yüzden CA policy'sini once "Report-only" modunda 7-14 gün çalıştırmak ve etki analizi yapmak kritiktir. Acil kapatma yerine kademeli yayılım önerilir.

Sonuç: Sistematik bir çözüm rutini

Microsoft Defender for Endpoint sensor health sorunları doğru sırayla yaklaşıldığında neredeyse her zaman support ticket açmadan çözülebilir. Temel rutin: önce cihazın gerçek durumunu (kullanılıyor mu, off-board mu, yeniden adlandırılmış mı) doğrulayın; sonra WinHTTP/proxy/firewall katmanını test edin; ardından Defender ve diagnostic servislerini yeniden başlatın; en son MDECA ile derinlemesine tanılama yapın.

Kurumsal ölçekte tek tek cihaz düzeltmeye çalışmak verimsizdir. Çözüm: Sensor health metriklerini izleyin, %3 eşiğini aştığında otomatik runbook tetikleyin (Power Automate veya Logic App), tekrarlayan cihazlarda Intune EDR policy'sini yeniden uygulatın. Microsoft Security stack'iniz ne kadar otomatik tepki verirse, manuel fix unhealthy sensors mesaisi de o kadar azalır.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Microsoft Defender for Endpoint dağıtım, sensor health izleme ve EDR runbook otomasyonu süreçlerinde uçtan uca destek veriyoruz. İletişim sayfamızdan bize ulaşın; sensor health envanterinizi birlikte sağlığa kavuşturalım.

Microsoft yolculuğunuzu
birlikte planlayalım

Mevcut altyapınızı ücretsiz değerlendirelim, doğru lisansı önerelim ve geçiş planınızı çıkaralım — aramayı uzmanlarımız 24 saat içinde yapar.

WhatsApp