Azure Virtual Desktop’ta 0x5000057 ve 0x807: Vaka Analizi
Sanal masaüstü ortamlarında arızanın en can sıkıcı biçimi, hiçbir şeyin bozuk görünmediği biçimdir. Sanal makineler açıktır, işletim sistemi yanıt verir, servisler çalışır durumdadır, portalda kırmızı bir uyarı yoktur. Buna rağmen kullanıcılar masaüstlerine bağlanamaz.
Aşağıda anlatılan vaka tam olarak böyle başladı. 15 host pool’dan oluşan bir Azure Virtual Desktop ortamında, farklı kullanıcılar farklı istemcilerden bağlanmayı denedi ve hepsi aynı duvara çarptı. Teşhis süreci, birbirini maskeleyen iki bağımsız arıza katmanı ortaya çıkardı; üstüne de ortamın neden bu duruma düştüğünü açıklayan yapısal bir eksik. Kurum, kullanıcı ve kaynak bilgileri anonimleştirildi; teknik akış olduğu gibi korundu.
Belirti: Makineler Ayakta, Havuz Boş
İlk bildirilen hata şuydu:
0x5000057 — There are currently no available resourcesMesaj kendi içinde tutarlı: istemci bağlanmak istiyor, servis ona verilebilecek bir oturum sunucusu bulamıyor. Ancak sanal makineler çalışır durumdaydı. Azure portalında VM’ler “Running” görünüyor, uzaktan yönetim çalışıyor, içeride AVD Agent servisi ayakta duruyordu.
Bu çelişki teşhisin başlangıç noktası oldu. Sanal makinenin açık olması, o makinenin host pool tarafından kullanılabilir sayıldığı anlamına gelmiyor. AVD’de makinenin güç durumu ile oturum sunucusu olarak kaydının geçerliliği birbirinden bağımsız iki durumdur ve portalın özet ekranları bu ikisini aynı yere koyma eğilimindedir.
Birinci Katman: Kaydın Sessizce Geçersizleşmesi
Host pool’ların session host listeleri incelendiğinde tablo netleşti. Havuzlarda makine kayıtları duruyordu, ancak bu kayıtlar servis tarafında artık geçerli değildi.
Mekanizma şöyle işliyor. Oturum sunucusundaki AVD Agent, kendi kayıt durumunu yerel olarak tutar ve kendini kayıtlı kabul eder. Servis tarafında kayıt geçersiz hâle geldiğinde agent bunu bir hata olarak yaşamaz; yeniden kaydolmayı dener. Fakat havuzda o makine adına ait eski bir kayıt hâlâ durmaktadır ve isim çakışması nedeniyle yeni kayıt oluşturulamaz. Agent ne başarılı olur ne de hata üretir — bekler.
Sonuç, dışarıdan bakıldığında sessiz bir arızadır. Makine açıktır, agent servisi çalışır, olay günlüğünde göze çarpan bir şey yoktur, ama havuz o makineyi bağlantıya uygun bir host olarak saymaz. Kullanıcı tarafında bunun karşılığı “şu anda kullanılabilir kaynak yok” mesajıdır.
Çözüm, kaydı yerinde onarmaya çalışmak değil sıfırlamaktır: havuzdaki eski session host kayıtları kaldırılır, yeni bir kayıt anahtarı üretilir ve makineler bu anahtarla havuza yeniden kaydedilir. 15 havuzun 14’ü bu işlemden sonra “Available” durumuna geçti.
Bu adımın ardından beklenmedik bir yan etki gözlendi ve teşhis açısından değerliydi: makineler, uzun süredir alamadıkları AVD Agent güncellemelerini otomatik olarak indirip kurdu. Güncellemeler servis üzerinden dağıtıldığı için, kayıt geçersizken makineler bu kanaldan da kopuktu. Yani arıza, fark edildiği günden çok daha önce başlamıştı; biriken güncellemeler bunun kanıtıydı.
İkinci Katman: Görmek ile Oturum Açmak Aynı Şey Değil
Kayıtlar onarıldıktan sonra kullanıcılar tekrar denedi. Hata kodu değişti:
0x807 — Your session ended because of an errorBu, ilerleme anlamına geliyordu. Bağlantı artık bir oturum sunucusu buluyor, “Securing connection” aşamasına kadar ilerliyor ve orada sonlanıyordu. Yani sorun artık kaynak bulmakta değil, o kaynakta oturum açmaktaydı.
Nedeni, Azure Virtual Desktop’ta sık karıştırılan bir yetki ayrımıydı. Kullanıcı grubuna Desktop Virtualization User rolü tanımlıydı; bu rol kullanıcının uygulama grubunu ve masaüstünü görmesini, bağlantıyı başlatmasını sağlar. Ancak Microsoft Entra ID’ye katılmış oturum sunucularında, kullanıcının makinede fiilen oturum açabilmesi için sanal makine üzerinde ayrıca Virtual Machine User Login rolünün bulunması gerekir. Bu rol tanımlı değildi.
İki rol farklı katmanlara aittir ve biri diğerini kapsamaz. Birincisi AVD nesnelerine erişimi, ikincisi işletim sistemi oturumunu yönetir. Bu yüzden kullanıcı masaüstünü listede görebiliyor, tıklayabiliyor, bağlantı kuruluyor ve tam kimlik doğrulama aşamasında düşüyordu.
Rol, tüm oturum sunucularını kapsayacak şekilde kaynak grubu seviyesinde tanımlandı. Burada kritik bir operasyonel ayrıntı var: yeni tanımlanan rol, kullanıcı istemciden çıkış yapıp yeniden giriş yapmadan devreye girmez. İstemci elindeki erişim belirtecini ancak böyle yeniler; eski belirteçle bağlanmaya devam eden kullanıcı aynı 0x807 hatasını almayı sürdürür. Bu adım atlandığında düzeltmenin işe yaramadığı sanılır ve teşhis gereksiz yere geri sarar.
Üçüncü Bulgu: Açık Ama Çalışmayan Bir Özellik
Ortamda Start VM on Connect özelliği host pool’larda etkin görünüyordu. Amacı basittir: kullanıcı bağlanmak istediğinde kapalı olan oturum sunucusu otomatik olarak açılır, böylece makineler boşta açık kalmaz.
Özellik etkindi ama çalışmıyordu. Sebebi, özelliğin kendisinin bir yetkiye bağlı olmasıydı. AVD servisinin sanal makinelerin güç durumunu okuyabilmesi ve onları başlatabilmesi için, servis ilkesine Desktop Virtualization Power On Contributor rolünün abonelik ya da kaynak grubu seviyesinde atanmış olması gerekir. Bu atama yapılmamıştı.
Buradaki tasarım tuzağı, özelliğin “Enabled” görünmesine rağmen sessizce etkisiz kalmasıdır. Portal, rolün eksik olduğunu bir uyarıyla bildirmez. Rol tanımlandıktan sonra özellik beklendiği gibi çalışmaya başladı.
Maliyet Tarafı: Onarılamayan Otomasyonlar
Arıza giderildikten sonra gündem maliyete kaydı. Onarım ve test süreci boyunca tüm oturum sunucuları açık bırakılmıştı ve açık kalan her makine fatura üretiyordu. Ortamda makineleri gece kapatması beklenen otomasyonlar vardı; ancak bunlar da çalışmıyordu.
İnceleme iki ayrı sorun gösterdi.
Birincisi, otomasyonlar portal üzerinden sanal makinenin Tasks menüsü kullanılarak oluşturulmuştu. Bu yolla üretilen görevler, oluşturuldukları sanal makineye managedBy alanı üzerinden kalıcı olarak bağlanır. İlgili makineler ortam yenilenirken değişmiş, adları farklılaşmış ve görevlerin referans verdiği kaynaklar ortadan kalkmıştı. Bu bağlantı bilgisi sonradan düzenlenemediği için görevler yerinde onarılamıyordu.
İkincisi daha öğretici: bu otomasyonların içinde e-posta bildirim adımları tanımlıydı, ancak bildirim özelliği kapalıydı. Yani görevler hiçbir zaman bildirim göndermedi. Çalışmadıkları da bu yüzden kimsenin dikkatini çekmedi. Bir otomasyonun sessiz kalması, başarılı olduğu anlamına gelmiyordu.
Görevleri onarmak yerine, Azure’un yerleşik Auto-shutdown özelliği devreye alındı: dış bağımlılığı yok, makineye değil kaynağın kendisine bağlı ve tüm 15 oturum sunucusunu kapsıyor. Eski otomasyonlar yalnızca 10 makineyi hedefliyordu; yani kapsam da eksikti.
İstenen Davranış Neden Kurulamadı
Maliyet tarafında asıl talep daha iddialıydı: kullanıcı bağlandığında makine açılsın, kullanıcı bağlantıyı kestiğinde yaklaşık 10 dakika, oturumu kapattığında yaklaşık 5 dakika sonra makine kendiliğinden deallocate edilsin.
Bu senaryo Azure Virtual Desktop’ta kurulabilir — ama her host pool tipinde değil.
Personal host pool’larda Scaling Plan oturum durumuna duyarlıdır: bağlantının kesilmesinden ve oturumun kapatılmasından sonra beklenecek süre ayrı ayrı tanımlanabilir ve eylem olarak deallocate seçilebilir. Talep edilen 10 dakika ve 5 dakika değerleri bu mimaride birebir uygulanabilir.
Pooled host pool’larda böyle bir ayar yoktur. Scaling Plan yalnızca zaman dilimlerine göre çalışır: ramp-up, peak, ramp-down ve off-peak. Belirli bir kullanıcının bağlantıyı kesmesinden N dakika sonra makineyi kapatma senaryosu desteklenmez — çünkü havuz modelinde bir makine birden çok kullanıcıya hizmet eder ve “oturum bitti” tek bir makineye karşılık gelmez.
Ortamdaki 15 havuzun tamamı Pooled tipindeydi. Dahası, host pool tipi oluşturulduktan sonra değiştirilemez; Resource Manager API’si bu alanın güncellenmesini desteklemez. Tip değişikliği ancak yeni bir host pool oluşturup oturum sunucularını oraya yeniden kaydetmekle mümkündür.
Pratik sonuç şu oldu: kısa vadede yerleşik Auto-shutdown ile gece kapatma kuruldu, Start VM on Connect ile bağlantıda otomatik açılma sağlandı. Gün içinde kullanılmayan bir makinenin akşama kadar açık kalması ise mevcut mimarinin kabul edilmesi gereken bir sınırı olarak kaldı. Talep edilen davranış bir ayar değil, bir mimari karardı.
Müdahale Kanalının Kendisi Arızalanırsa
15 makineden biri bu çalışmanın dışında kaldı ve ayrı bir sorun sınıfını temsil ettiği için not etmeye değer. Bu makinede Azure Guest Agent işletim sistemi içinde yanıt vermiyordu.
Bu durumun özelliği, bir kısır döngü üretmesidir. Azure’un uzaktan müdahale yöntemlerinin önemli bir bölümü — komut çalıştırma, parola sıfırlama, uzantı kurma — tam olarak bu agent üzerinden işler. Agent yanıt vermediğinde, onu onarmak için kullanılacak araçlar da devre dışı kalır. Yeniden başlatma ve makineyi farklı bir sunucuya taşıma denendi, sonuç alınamadı.
Geriye kalan yollar konsol erişimi ya da diski ayırıp başka bir makineye bağlayarak incelemektir. Bu tür bir müdahaleye girmeden önce atılan adım ise basit ve pahalı olmayan bir sigortadır: diskin anlık görüntüsü alınır. Böylece onarım denemeleri veri kaybı riski taşımaz.
Görünmeyen Eksik: Tanılama Olmayınca Arıza da Yok Sayılır
Teşhis tamamlandığında geriye tek bir soru kalıyordu: bu arıza neden bu kadar geç fark edildi?
Cevap ortamın kendisindeydi. Abonelikte bir Log Analytics çalışma alanı bulunmuyordu; dolayısıyla AVD tanılama kayıtları hiçbir yere toplanmıyordu. Azure Virtual Desktop Insights da bu çalışma alanına dayandığı için kullanılamıyordu. Bağlantı denemeleri, başarısız oturumlar, host sağlık durumları — hiçbiri kayıt altına alınmıyordu.
Böyle bir ortamda arızanın tek bildirim kanalı kullanıcıdır. Kullanıcı şikâyet edene kadar sistem “çalışıyor” sayılır. Session host kayıtlarının ne zaman geçersizleştiği, biriken agent güncellemelerinden tahmin edilebildi; ölçülemedi.
İkinci bir yapısal eksik de aynı denetimde görüldü: oturum sunucuları için yapılandırılmış bir yedekleme bulunmuyordu. Kullanıcı profilleri ve uygulama ayarları makinelerin yerel disklerinde tutulduğu için, bir disk arızasında geri dönüş imkânı olmayacaktı.
Yapılan İşlemlerin Özeti
| Bulgu | Uygulanan işlem |
|---|---|
| Bayat session host kayıtları | Eski kayıtlar kaldırıldı, yeni anahtarla yeniden kayıt yapıldı |
| Kullanıcı oturum açamıyor (0x807) | Virtual Machine User Login rolü kaynak grubu seviyesinde tanımlandı |
| Start VM on Connect etkisiz | AVD servis ilkesine Power On Contributor rolü verildi |
| Gece kapatma otomasyonları ölü | Yerleşik Auto-shutdown devreye alındı, kapsam 10 makineden 15 makineye çıktı |
| Disconnect/logoff sonrası kapatma | Karşılanamadı — Pooled mimaride desteklenmiyor |
| Guest agent yanıt vermiyor | Disk anlık görüntüsü alındı, konsol düzeyi müdahaleye bırakıldı |
| Tanılama ve yedekleme yok | Log Analytics çalışma alanı ve Azure Backup kurulumu önerildi |
Çıkarılan Dersler
- Açık makine, kullanılabilir host demek değildir. Güç durumu ile session host kaydının geçerliliği birbirinden bağımsızdır; teşhise host pool’un session hosts listesinden başlayın.
- Sessizlik sağlık göstergesi değildir. AVD Agent kaydı geçersizleştiğinde hata üretmeden bekler. Aynı şekilde, bildirim göndermeyen bir otomasyon da çalıştığını kanıtlamaz.
- Görme yetkisi ile oturum açma yetkisi ayrı katmanlardır. Entra ID’ye katılmış oturum sunucularında Desktop Virtualization User tek başına yetmez; Virtual Machine User Login rolü de gerekir.
- Yeni rol, yeniden oturum açmadan devreye girmez. Yetki değişikliğinden sonra kullanıcıya istemciden çıkış yapıp yeniden giriş yaptırın; aksi hâlde düzeltme işe yaramamış görünür.
- Etkinleştirilmiş özellik, çalışan özellik değildir. Start VM on Connect, arkasındaki rol ataması olmadan sessizce etkisiz kalır.
- Host pool tipi geri dönülemez bir karardır. Oturum durumuna duyarlı kapatma gerekiyorsa Personal tipi baştan seçilmelidir; sonradan dönüş yeni havuz kurmayı gerektirir.
- Müdahale kanalını da hesaba katın. Guest agent üzerinden çalışan araçlar, agent arızalandığında kullanılamaz; konsol erişimi ve disk anlık görüntüsü bu durumda tek çıkıştır.
- Tanılama altyapısı arızadan önce kurulur. Log Analytics çalışma alanı olmayan bir ortamda arızanın ne zaman başladığı sonradan ölçülemez, yalnızca tahmin edilir.
Kaynaklar
- Troubleshoot Azure Virtual Desktop Agent issues — Agent kayıt hatalarının tam listesi; isim çakışması, süresi geçmiş kayıt anahtarı ve havuzdan kaldırıp yeniden kaydetme prosedürü burada anlatılıyor.
- Microsoft Entra joined session hosts in Azure Virtual Desktop — Entra ID’ye katılmış oturum sunucularında oturum açmak için gereken rol atamaları.
- Configure Start VM on Connect — Özelliğin çalışması için AVD servis ilkesine atanması gereken Power On Contributor rolü.
- Create and assign an autoscale scaling plan — Pooled ve Personal host pool’larda ölçekleme seçeneklerinin farkı.
- Enable Insights to monitor Azure Virtual Desktop — Tanılama verilerinin toplanması için gereken Log Analytics çalışma alanı.
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
Yorum gönder