Azure Virtual Desktop 'Unavailable' Hatası: Kök Neden ve Çözüm (2026)

Özet (TL;DR): Azure Virtual Desktop'ta (Microsoft'un bulutta çalışan sanal masaüstü hizmeti) oturum konağının (session host — kullanıcıların bağlandığı sanal makine) host pool'da (aynı masaüstü havuzunu paylaşan sunucu grubu) sürekli "Unavailable" görünmesinin dört yaygın kök nedeni vardır: durmuş RDAgentBootLoader servisi, süresi dolmuş veya geçersiz kayıt anahtarı, engellenmiş ağ/güvenlik duvarı erişimi ve başarısız ajan güncellemesi. Microsoft'un resmi tanı sırası önce Olay Görüntüleyicisi'nde (Event Viewer) WVD-Agent ve RDAgentBootLoader kaynaklı olayları incelemek, sonra Get-AzWvdSessionHost ile durumu doğrulamaktır. Kayıt anahtarı en fazla 27 gün geçerli üretilebilir — bu süre dolduğunda konak sessizce "Unavailable"a düşer. Bu yazıda belirtilerden hata koduna, adım adım çözümden Türkiye'den bağlanan kullanıcılar için gecikme ve KVKK notlarına kadar tüm süreci; Microsoft'un resmi Azure Virtual Desktop ajan sorun giderme ve oturum konağı yapılandırma sorun giderme makalelerine dayanarak anlatıyoruz.

Xen Bilişim ekibi · Microsoft Kayıtlı İş Ortağı (2016'dan bu yana) · Azure altyapı ve uç nokta yönetimi konusunda AZ-104/MS-102 sertifikalı danışmanlar. Bu yazıdaki hata mesajları, servis adları ve ekran görüntüleri Microsoft'un resmi destek dokümantasyonundan alınmıştır; son güncelleme tarihleri makale içinde belirtilmiştir.

Session host'larınız sabah kontrolünde toplu halde "Unavailable" görünüyorsa ve kullanıcılar masaüstüne bağlanamıyorsa vakit kaybetmeyin — Xen Bilişim'den ücretsiz teknik görüşme talep edin, ortamınızı birlikte 15 dakikada teşhis edelim.

Belirtiler: "Unavailable" Durumu Nasıl Görünür?

Azure portalında Host pools → Session Hosts sekmesine girdiğinizde, sorunlu konaklar üç farklı durumdan birinde takılı kalır ve bunları birbirinden ayırmak doğru çözüme giden ilk adımdır:

• Unavailable — konak, Microsoft'un tanımladığı sağlık kontrollerinden (health check) birini geçemiyor; en sık görülen durum.
• Needs Assistance — konak çalışıyor ama UrlsAccessibleCheck, MetaDataServiceCheck veya MonitoringAgentCheck kontrollerinden biri kısmen başarısız; kullanıcı bağlanabilir ama performans/izleme riski var.
• Upgrading — ajan veya yığın (side-by-side stack) güncellemesi yarıda kalmış; genelde qwinsta komutunda rdp-sxs girdisinin Listen durumunda olmadığı görülür.

Kullanıcı tarafında görülen tipik belirtiler: masaüstü istemcisinde "Şu anda bu kaynak kullanılamıyor", bağlantı sırasında uzun süre dönen yükleme çemberi, veya IT yöneticisinin Get-AzWvdSessionHost çıktısında Status: Unavailable, LastHeartBeat alanının saatler önce donduğunu görmesidir. Sorunun toplu mu (tüm host pool) yoksa tekil mi (bir VM) olduğunu belirlemek, kök neden analizini önemli ölçüde hızlandırır.

Hata Kodları ve Sağlık Kontrolü Eşleme Tablosu

Olay Görüntüleyicisi'nde (Event Viewer > Windows Logs > Application) WVD-Agent, RDAgentBootLoader veya MsiInstaller kaynaklı olayları filtreleyin. Aşağıdaki tablo, Microsoft'un resmi sorun giderme makalesinde listelenen olay kimliklerini ve anlamlarını özetler:

Olay / Açıklama	Anlamı	İlk kontrol
Event ID 3277 — INVALID_REGISTRATION_TOKEN / EXPIRED_MACHINE_TOKEN	Kayıt anahtarı geçersiz veya süresi dolmuş	Yeni anahtar üret, registry'i güncelle
Event ID 3277 — INVALID_FORM	Ajan, broker'a (aracı hizmet) ulaşamıyor	Güvenlik duvarı/DNS engeli kontrol et
Event ID 3703 — RD Gateway Url is not accessible	Gerekli URL listesi engelli	Required URL Check aracını çalıştır
Event ID 3019	WebSocket taşıma URL'lerine erişilemiyor	Proxy/güvenlik duvarı ekibiyle kontrol
Event ID 3277 — ENDPOINT_NOT_FOUND	Host pool'da aktif/uygun VM yok	VM açık mı, oturum limiti dolmuş mu bak
Event ID 3389 — MissingMethodException	.NET Framework sürümü 4.7.2 altında	.NET Framework güncelle
UrlsAccessibleCheck başarısız	Zorunlu URL listesi engelleniyor (güvenlik duvarı/hosts dosyası)	443/80 portlarını aç
MetaDataServiceCheck başarısız	IMDS'e (Instance Metadata Service — sanal makinenin kendi bilgilerini sorguladığı dahili Azure servisi) 169.254.169.254 adresinden erişim yok	Proxy bypass listesine ekle
DomainJoinCheck / DomainTrustCheck başarısız	VM etki alanına (domain) katılamıyor veya güven ilişkisi bozuk	DNS/VNet peering, MFA'sız hizmet hesabı kontrol et

Bu tablo referans olsun diye tutulmalı — birebir aynı olay kimliğini görmeseniz bile açıklama sütunu doğru kategoriye (kayıt, ağ, kimlik, güncelleme) yönlendirir.

Kök Neden Analizi: Dört Ana Senaryo

Microsoft'un resmi sorun giderme makalelerini ve Microsoft Q&A'da 2026 içinde açılan güncel destek konularını (ör. "Session host is unavailable", "session hosts stuck in Unavailable state (DomainJoinCheck & DomainTrustCheck failed)") birlikte değerlendirdiğimizde, kök neden neredeyse her zaman şu dört kategoriden birine düşüyor:

1) RDAgentBootLoader servisi durmuş veya başlamıyor

Hizmetler (Services) penceresinde Remote Desktop Agent Loader durdurulmuş görünüyor veya listede hiç yok. Bu, ajanın önyükleyicisinin ajanı düzgün kuramadığı anlamına gelir. Windows önyüklemesinde servis zamanında başlamazsa (Event 7000/7011) konak da sağlıksız görünür.

2) Kayıt anahtarı (registration token) süresi dolmuş

Host pool için üretilen kayıt anahtarı en az bir saat, en fazla 27 gün geçerli olacak şekilde ayarlanabilir. Kısa süreli test anahtarı unutulup üretime alınırsa, süre dolduğunda konak sessizce "Unavailable"a düşer — herhangi bir uyarı gelmez, yalnızca IsRegistered kayıt defteri (registry) değeri sıfırlanır.

3) Ağ/güvenlik duvarı zorunlu URL'leri engelliyor

Kurumsal güvenlik duvarı, proxy veya yerel hosts dosyası, Azure Virtual Desktop'ın çalışması için zorunlu olan URL listesini (broker, gateway, WebSocket uç noktaları) engellediğinde ajan sağlıklı görünse bile broker'a bağlanamaz. IMDS uç noktası 169.254.169.254'ün proxy'den muaf tutulmaması da aynı sonucu doğurur.

4) Ajan/yığın güncellemesi yarıda kalmış

Disk alanı yetersizliği (DownloadMsiException), grup ilkesiyle msiexec.exe veya cmd.exe engellenmesi, ya da desteklenmeyen bir işletim sistemi sürümü (Pro sürüm, Enterprise/Server değil) kullanmak, yan yana ağ yığınının (side-by-side stack) düzgün kurulmasını engeller ve konak Upgrading durumunda takılı kalır.

Adım Adım Çözüm (En Kolaydan En Zora)

Adım 1 — RDAgentBootLoader servisini yeniden başlatın

1. Session host'a yönetici olarak bağlanın, Hizmetler (services.msc) penceresini açın.
2. Remote Desktop Agent Loader üzerine sağ tıklayıp Başlat'ı seçin.
3. 10 saniye bekleyip Yenile'ye basın. Servis tekrar durursa, kayıt sorunu (Adım 2) devreye giriyor demektir.

Adım 2 — Kayıt anahtarını yenileyin

Azure portalında host pool'un Overview sayfasından Registration key → Generate new key ile yeni bir anahtar üretin (aşağıdaki ekran görüntüsünde bu düğmenin yeri işaretli), süresini ihtiyacınız kadar (en fazla 27 gün) belirleyin, ardından session host'ta PowerShell'i yönetici olarak açıp şu komutları çalıştırın:

$newKey = '<YeniKayitAnahtari>'
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name "IsRegistered" -Value 0 -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name "RegistrationToken" -Value $newKey -Force
Restart-Service RDAgentBootLoader

# Doğrulama — IsRegistered 1 ve RegistrationToken boş dönmeli
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name IsRegistered | FL IsRegistered
Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\RDInfraAgent" -Name RegistrationToken | FL RegistrationToken

Adım 3 — Ağ erişimini doğrulayın

Session host'tan TCP 443 ve UDP 3391 portlarının açık olduğunu, IMDS uç noktasının (169.254.169.254) proxy'den muaf tutulduğunu doğrulayın:

# Broker'a 443 üzerinden erişim testi (PSPing gerekir)
psping rdbroker.wvdselfhost.microsoft.com:443

# IMDS'i proxy bypass listesine ekleme
netsh winhttp set proxy proxy-server="http=<proxy-adresiniz>" bypass-list="169.254.169.254"

Eğer bağlantı zaman aşımına uğruyorsa, güvenlik ekibinizle Microsoft'un zorunlu URL listesini paylaşıp güvenlik duvarı/proxy istisnasına ekletin.

Adım 4 — Temiz kurulum (önceki adımlar çözmediyse)

1. Session host'ta Programlar ve Özellikler'den şu bileşenlerin tamamını kaldırın: Remote Desktop Agent Boot Loader, Remote Desktop Services Infrastructure Agent, Remote Desktop Services Infrastructure Geneva Agent, Remote Desktop Services SxS Network Stack.
2. Azure portalında host pool'dan bu session host'u Session Hosts sekmesinden kaldırın (Remove).
3. Yeni bir kayıt anahtarı üretin (Adım 2'deki gibi, süre azami 27 gün).
4. Güncel Azure Virtual Desktop Agent ve Boot Loader kurulumlarını sırayla çalıştırıp yeni anahtarı girin.
5. VM'yi yeniden başlatın ve portalda durumun Available'a döndüğünü doğrulayın.

Ortamınızda bu adımları tek başınıza yürütmek yerine bir uzmanla birlikte gözden geçirmek isterseniz WhatsApp'tan Xen Bilişim'e yazın, 15 dakikalık ücretsiz teknik görüşmede ortamınızı birlikte inceleyelim.

Senaryoya Özel Dallar

Tek konak mı, tüm host pool mu? Tek bir VM etkileniyorsa kök neden genelde o makineye özgüdür (disk doluluğu, yerel grup ilkesi). Tüm host pool aynı anda "Unavailable" ise sorun kayıt anahtarı süresi veya paylaşılan ağ/güvenlik duvarı kuralıdır — tek tek VM'lerle uğraşmadan önce bunu kontrol edin.

Microsoft Entra ID join mi, geleneksel Active Directory domain join mi? Entra ID-only dağıtımlarda DomainJoinCheck/DomainTrustCheck hataları genelde VNet DNS ayarlarının Entra Domain Services'e işaret etmemesinden kaynaklanır. Klasik AD domain join'de ise en sık neden, VM'lerin domain controller'ın bulunduğu sanal ağa (VNet) eşlenmemiş (peering yapılmamış) olmasıdır.

Windows 10/11 çoklu oturum (multi-session) mu, Windows Server mı? Yalnızca Windows Enterprise veya Server sürümleri yan yana ağ yığınını (side-by-side stack) destekler; bir Pro sürüm imajı kullanıyorsanız yığın hiç etkinleşmez ve konak asla sağlıklı görünmez — altın imajınızın (golden image) sürümünü kontrol edin.

Yönetici Tarafı Kontroller ve Önleyici Bakım

• Kayıt anahtarı takvimi tutun: Anahtar azami 27 gün geçerli üretilebildiği için, otomasyon veya golden image güncelleme sürecinizde anahtar yenileme tarihini takvime ekleyin.
• Azure Monitor uyarısı kurun: Host pool sağlık durumu için SessionHostHealthCheckFailed tabanlı uyarı kuralları, sorunu kullanıcı şikayet etmeden önce yakalar.
• RDAgentBootLoader'ı gecikmeli otomatik başlatmaya alın: Açılışta servis zamanında ayağa kalkmıyorsa, hizmet özelliklerinden başlangıç türünü Otomatik (Gecikmeli Başlangıç) yapmak açılış baskısını (boot pressure) azaltır.
• Golden image'e ajanı önceden kurmayın: Ajan yalnızca imaj dağıtıldıktan sonra kurulmalı; imajın kendisine gömülü ajan, kayıt çakışmalarına yol açar.
• Oturum limitini izleyin: ENDPOINT_NOT_FOUND hatasının bir nedeni de host pool'daki tüm VM'lerin maksimum oturum sınırına ulaşmasıdır — kapasite planlamasını otomatik ölçeklendirme (autoscale) kurallarıyla destekleyin.

Türkiye'den Bağlanırken Dikkat Edilmesi Gerekenler

Azure'ın Türkiye'de yerel bir bölgesi (region) bulunmuyor; Türkiye'deki kullanıcılar genelde West Europe veya North Europe bölgesindeki host pool'lara bağlanıyor. Bu, "Unavailable" sorunuyla doğrudan ilgili olmasa da iki pratik sonucu var: (1) İstanbul-Amsterdam arası tipik gecikme (round-trip latency) 35-45 milisaniye civarında seyreder — RDP deneyimi çoğu ofis işi için yeterli olsa da, düşük gecikme gerektiren CAD/render işlerinde performans beklentisini önceden yönetin; (2) oturum verisi ve profil verileri (FSLogix ile taşınan kullanıcı profilleri) Avrupa Birliği sınırları içinde kalıyor olsa da, KVKK kapsamında yurt dışına veri aktarımı değerlendirmesi (Standart Sözleşme, açık rıza veya Kurul kararlarındaki istisnalardan biri) proje başında netleştirilmeli — bu konuda hukuk/uyum ekibinizle birlikte çalışmanızı öneririz.

Bir diğer TR-özel tuzak: Türkçe karakter içeren kullanıcı adı veya UPN'lerde (ör. "öğrenci.özkan@sirket.com") bazı eski görüntü (image) şablonlarında oturum açma veya profil senkronizasyonu sırasında kodlama (encoding) sorunları görülebiliyor. Yeni bir host pool kurarken test kullanıcılarından en az birine bilerek Türkçe karakterli bir UPN vererek uçtan uca test etmenizi öneririz.

Saha Vakası: 40 Kişilik Mühendislik Bürosunda Sabah Kilidi

Firma X — 40 kişilik yapı mühendisliği bürosu — hibrit çalışma için kurulu tek host pool

Bir mühendislik bürosu, saha ekiplerinin proje dosyalarına her yerden erişmesi için tek host pool'lu bir Azure Virtual Desktop kurulumu işletiyordu. Bir pazartesi sabahı host pool'daki 6 session host'un tamamı aynı anda "Unavailable" durumuna düştü; 40 kullanıcı da masaüstüne bağlanamadı. İlk bakışta VM'lerin kapalı olmadığı, ancak Get-AzWvdSessionHost çıktısında LastHeartBeat alanının 30 saat önce donduğu görüldü — bu süre, cuma günü test amaçlı üretilmiş kısa ömürlü bir kayıt anahtarının geçerlilik süresine denk geliyordu.

Süre: Teşhis ve çözüm toplam 55 dakika sürdü. Karar noktaları: (1) Sorunun tek VM değil tüm host pool'u etkilemesi, ekibi doğrudan kayıt anahtarı/ağ katmanına yönlendirdi; (2) Event Viewer'da EXPIRED_MACHINE_TOKEN ile eşleşen Event ID 3277 kaydı bulundu; (3) Yeni bir kayıt anahtarı 27 günlük azami süreyle üretildi ve altı VM'ye PowerShell script'iyle toplu uygulandı; (4) İleride aynı hatayı önlemek için host pool'un otomasyon sürecine "anahtar yenileme" takvim hatırlatıcısı eklendi. Sonuç: Kullanıcılar aynı sabah 10:00'a kadar tekrar bağlanabildi, bir daha benzer kesinti yaşanmadı. Xen ekibinin rolü: Uzaktan teşhis, toplu kayıt anahtarı yenileme ve önleyici takvim sürecinin kurulması. Uyarı: Kısa ömürlü test anahtarlarını üretim host pool'unda asla kalıcı anahtar yerine kullanmayın; anahtar süresini üretimde her zaman ihtiyacınız kadar (mümkünse 27 güne yakın) belirleyin.

Azure altyapı yönetimi hizmetlerimizi inceleyin veya ortamınızın ücretsiz sağlık kontrolünü talep edin.

Benzer Hatalarla Farkı

"Unavailable" durumunu, sık karıştırılan komşu hatalardan ayırmak zaman kazandırır:

• Needs Assistance — konak kısmen çalışıyor, kullanıcı bazen bağlanabiliyor; kök neden genelde ağ erişimi (URL/IMDS) kontrollerinden biri, tam kopukluk değil.
• Upgrading'de takılı kalma — ajan güncellemesi yarıda kalmış; çözüm yığının (side-by-side stack) yeniden kurulmasıdır, kayıt anahtarı yenilemek tek başına yetmez.
• Windows 365 Cloud PC "provisioning failed" — görünüşte benzer bir "bulut masaüstüne bağlanamıyorum" şikayeti üretir, ama Windows 365'te sorun neredeyse hiç ajan/kayıt anahtarı kaynaklı değildir; genelde lisans ataması veya ağ profili eksikliğidir. İki ürünü karıştırmayın; tanı adımları farklıdır.
• Sıradan bir Azure VM'e RDP ile bağlanamama — Azure Virtual Desktop katmanı hiç devrede değildir; sorun doğrudan NSG (ağ güvenlik grubu), genel IP veya Bastion yapılandırmasındadır.

Sıkça Sorulan Sorular (SSS)

Azure Virtual Desktop kullanmak için ayrı bir lisans mı almam gerekiyor?

Hayır. Azure Virtual Desktop'a erişim için ayrı bir ürün lisansı yoktur; mevcut Windows, Microsoft 365 veya Windows Server için RDS CAL (Remote Desktop Services istemci erişim lisansı) hakkınız varsa erişim bu lisansa dahildir. Ayrıca ödediğiniz kalem, session host'ların çalıştığı Azure sanal makine altyapısı ve depolamadır — bunun fiyatı VM boyutuna göre değişir, güncel rakam için Microsoft'un resmi fiyatlandırma sayfasından teyit alın.

Session host'u yeniden başlatmak "Unavailable" durumunu çözer mi?

Bazen evet, ama kalıcı çözüm değildir. Sorun kayıt anahtarı süresinin dolmasıysa yeniden başlatma durumu değiştirmez; servis her açılışta aynı geçersiz anahtarla kaydolmaya çalışıp tekrar başarısız olur. Önce Event Viewer'da kök nedeni doğrulamadan sadece yeniden başlatmak, sorunu ertelemekten öteye geçmez.

Kaç günde bir kayıt anahtarı yenilemem gerekir?

Sabit bir zorunluluk yoktur ama Microsoft anahtarı en fazla 27 gün geçerli üretmenize izin verir. Üretim ortamlarında anahtarı ihtiyacınız kadar uzun (mümkünse azami süreye yakın) üretip otomasyon sürecinize bir yenileme hatırlatıcısı eklemenizi öneririz — aksi halde sessiz bir kesinti yaşarsınız.

Tüm host pool aynı anda "Unavailable" olduysa nereden başlamalıyım?

Tek VM değil tüm havuz etkileniyorsa önce paylaşılan nedenlere bakın: kayıt anahtarı süresi, güvenlik duvarı/proxy'de yakın zamanda yapılan bir değişiklik, ya da bölgesel bir Azure hizmet kesintisi. Tek tek VM'lerin yerel ayarlarıyla uğraşmadan önce bu üç noktayı elemek büyük zaman kazandırır.

Golden image'e Azure Virtual Desktop ajanını önceden kurabilir miyim?

Önerilmez. Microsoft'un resmi rehberi, ajanın yalnızca VM'ler dağıtıldıktan ve host pool'a eklendikten sonra kurulmasını söyler. Ajan imajın kendisine gömülüyse, her yeni VM aynı makine kimliğiyle kaydolmaya çalışır ve NAME_ALREADY_REGISTERED gibi çakışma hataları ortaya çıkar.

Sorunu kendimiz çözemezsek Microsoft desteğine mi, iş ortağımıza mı başvurmalıyız?

Bu yazıdaki adımlar sonuç vermezse iki yol da geçerli: Microsoft destek kaydı açabilir (ağ izleme günlüklerinizi eklemeniz istenecektir) veya Microsoft Kayıtlı İş Ortağınızdan (Xen Bilişim gibi) uzaktan teşhis desteği alabilirsiniz. İkincisi genelde daha hızlıdır çünkü ortamınıza ve önceki yapılandırmanıza zaten aşinadır.

Türkiye'deki kullanıcılar için hangi Azure bölgesi önerilir?

Türkiye'de yerel bir Azure bölgesi bulunmadığı için pratikte West Europe (Hollanda) veya North Europe (İrlanda) tercih edilir; ikisi arasındaki seçim genelde mevcut diğer Azure kaynaklarınızın (depolama, Entra ID kiracı bölgesi) nerede olduğuna göre yapılır. Gecikme farkı iki bölge arasında küçüktür, ofis işleri için ikisi de yeterlidir.

Sonuç: Sistemli Tanı, Tek Seferde Kalıcı Çözüm

Azure Virtual Desktop'ta "Unavailable" hatası korkutucu görünse de, arkasındaki nedenler sınırlı ve Microsoft'un resmi dokümantasyonunda net biçimde tanımlanmıştır: durmuş bir servis, süresi dolmuş bir anahtar, engellenmiş bir ağ yolu veya yarım kalmış bir güncelleme. Doğru sırayla ilerlemek — önce Event Viewer, sonra Get-AzWvdSessionHost, ardından kök nedene özel çözüm — çoğu vakada bir saatten kısa sürede kalıcı sonuç verir.

Asıl değer, sorunu tekrar tekrar çözmek yerine önlemektir: kayıt anahtarı takvimi, Azure Monitor uyarıları ve golden image disiplini kurulduğunda bu hata neredeyse hiç görünmez hale gelir. Türkiye'deki kurumlar için buna bir de bölge/gecikme ve KVKK değerlendirmesi eklenmeli — bunlar teknik hatayı değil ama kullanıcı deneyimini ve uyumu etkiler.

Ortamınızda Azure Virtual Desktop kurulumu, bakımı veya bu tür kesintilerin önlenmesi için destek arıyorsanız, Windows ve uç nokta yönetimi ile Azure altyapı hizmetlerimize göz atabilir ya da doğrudan bize yazabilirsiniz.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun Azure Virtual Desktop benimseme ve kesintisiz işletme yolculuğunda kurulumdan izlemeye, olay müdahalesinden önleyici bakıma kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın.