Aracılığıyla paylaş


Azure Windows VM uzantısı hatalarında sorun giderme

Azure Resource Manager şablonlarına genel bakış

Azure Resource Manager şablonları, kaynaklar arasındaki bağımlılıkları tanımlayarak Azure IaaS altyapısını JSON dilinde bildirimli olarak belirtmenize imkan sağlar.

Uzantıları kullanma amacıyla şablon yazma hakkında daha fazla bilgi edinmek için bkz. Uzantı şablonları yazma.

Bu makalede, bazı yaygın VM uzantısı hatalarıyla ilgili sorunları gidermeyi öğreneceksiniz.

Uzantı durumunu görüntüleme

Azure Resource Manager şablonları Azure PowerShell'den yürütülebilir. Şablon yürütüldükten sonra uzantı durumu Azure Kaynak Gezgini'nden veya komut satırı araçlarından görüntülenebilir.

Bir örnek aşağıda verilmiştir:

Azure PowerShell:

Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status

Örnek çıktı şu şekildedir:

Extensions:  {
  "ExtensionType": "Microsoft.Compute.CustomScriptExtension",
  "Name": "myCustomScriptExtension",
  "SubStatuses": [
    {
      "Code": "ComponentStatus/StdOut/succeeded",
      "DisplayStatus": "Provisioning succeeded",
      "Level": "Info",
      "Message": "    Directory: C:\\temp\\n\\n\\nMode                LastWriteTime     Length Name
          \\n----                -------------     ------ ----                              \\n-a---          9/1/2015   2:03 AM         11
          test.txt                          \\n\\n",
                  "Time": null
      },
    {
      "Code": "ComponentStatus/StdErr/succeeded",
      "DisplayStatus": "Provisioning succeeded",
      "Level": "Info",
      "Message": "",
      "Time": null
    }
  ]
}

Uzantı hatalarını giderme

VM Aracısı'nın çalıştığını ve Hazır olduğunu doğrulayın

Uzantıları yönetmek, yüklemek ve yürütmek için VM Aracısı gereklidir. VM Aracısı çalışmıyorsa veya Azure platformuna Hazır durumu bildiremiyorsa uzantılar düzgün çalışmaz.

VM Aracısı sorunlarını gidermek için lütfen aşağıdaki sayfalara bakın:

Uzantınızla ilgili sorun giderme kılavuzunuzu denetleyin

Bazı uzantıların sorunlarını gidermeyi açıklayan belirli bir sayfası vardır. Bu uzantıların ve sayfaların listesini Uzantı sorunlarını giderme sayfasında bulabilirsiniz.

Uzantının durumunu görüntüleme

Yukarıda açıklandığı gibi, Uzantının durumu PowerShell cmdlet'i çalıştırılarak bulunabilir:

Get-AzVM -ResourceGroupName $RGName -Name $vmName -Status

veya CLI komutu:

az vm extension show -g <RG Name> --vm-name <VM Name>  --name <Extension Name>

veya Azure portalında, VM Dikey Penceresine / Ayarlar / Uzantılar'a göz atarak. Ardından uzantıya tıklayıp durumunu ve iletisini de kontrol edebilirsiniz.

VM'de uzantıyı yeniden çalıştırma

Özel Betik Uzantısı'nı kullanarak VM'de betik çalıştırıyorsanız bazen VM'nin başarıyla oluşturulduğu ancak betiğin başarısız olduğu bir hatayla karşılaşabilirsiniz. Bu koşullar altında, bu hatadan kurtarmanın önerilen yolu uzantıyı kaldırmak ve şablonu yeniden çalıştırmaktır. Not: Gelecekte bu işlevsellik, uzantıyı kaldırma gereksinimini ortadan kaldıracak şekilde geliştirilecek.

Uzantıyı Azure PowerShell'den kaldırma

Remove-AzVMExtension -ResourceGroupName $RGName -VMName $vmName -Name "myCustomScriptExtension"

Uzantı kaldırıldıktan sonra şablon, betikleri VM'de çalıştırmak için yeniden yürütülebilir.

VM'ye yeni bir GoalState tetikleme

Bir uzantının yürütülmediğini veya eksik bir "Windows Azure CRP Sertifika Oluşturucu" nedeniyle yürütülemediğini fark edebilirsiniz (bu sertifika uzantının korumalı ayarlarının taşınmasını sağlamak için kullanılır). Bu sertifika, Sanal Makinenin içinden Windows Konuk Aracısı yeniden başlatılarak otomatik olarak yeniden oluşturulur:

  • Görev Yöneticisi'ni açma
  • Ayrıntılar sekmesine gidin
  • WindowsAzureGuestAgent.exe işlemini bulma
  • Sağ tıklayın ve "Görevi Sonlandır"ı seçin. İşlem otomatik olarak yeniden başlatılır

Ayrıca bir "VM Yeniden Uygulama" yürüterek vm için yeni bir GoalState tetikleyebilirsiniz. VM Reapply , bir VM'nin durumunu yeniden uygulamak için 2020'de kullanıma sunulan bir API'dir. Bunu, kısa bir VM kapalı kalma süresini tolere edebildiğiniz bir zamanda yapmanızı öneririz. Reapply'nin kendisi VM'yi yeniden başlatmaya neden olmaz ve çoğu zaman Reapply çağrısı vm'yi yeniden başlatmaz, ancak Reapply yeni bir hedef durumu tetiklediğinde VM modelinde bekleyen başka bir güncelleştirmenin uygulanması ve başka bir değişikliğin yeniden başlatılması gerekmesi çok küçük bir risktir.

Azure portalı:

Portalda VM'yi seçin ve sol bölmede Destek + sorun giderme altında Yeniden dağıt + yeniden uygulama'yı ve ardından Yeniden Uygulama'yı seçin.

Azure PowerShell (RG Adı ve VM Adı değerleriniz ile değiştirin):

Set-AzVM -ResourceGroupName <RG Name> -Name <VM Name> -Reapply

Azure CLI (RG Adı ve VM Adı değerleriniz ile değiştirin):

az vm reapply -g <RG Name> -n <VM Name>

"VM Yeniden Uygulama" işe yaramadıysa, Azure Yönetim Portalı'ndan VM'ye yeni bir boş Veri Diski ekleyebilir ve sertifika geri eklendikten sonra daha sonra kaldırabilirsiniz.

VM'nin içindeki uzantı günlüklerine bakın

Önceki adımlar işe yaramadıysa ve uzantınız hala başarısız durumdaysa, sonraki adım Sanal Makine içindeki günlüklerine bakmaktır.

Windows VM'sinde uzantı günlükleri genellikle

C:\WindowsAzure\Logs\Plugins

Uzantı ayarları ve durum dosyaları

C:\Packages\Plugins

Linux VM'sinde uzantı günlükleri genellikle

/var/log/azure/

Uzantı ayarları ve durum dosyaları

/var/lib/waagent/

Her uzantı farklıdır ancak genellikle benzer ilkelere uyar:

Uzantı paketleri ve ikili dosyalar VM'ye indirilir (örn. " Linux için /var/lib/waagent/custom-script/download/1" veya Windows için "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Downloads\0" ).

Yapılandırmaları ve ayarları Azure Platformu'ndan VM Aracısı aracılığıyla uzantı işleyicisine geçirilir (örn. " Linux için /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/config" veya Windows için "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\RuntimeSettings"

VM'nin içindeki uzantı işleyicileri bir durum dosyasına yazıyor (örn. " Linux için /var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/status/1.status" veya "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Status" daha sonra Azure Platformu'na bildirilecektir. Bu durum, PowerShell, CLI aracılığıyla veya Azure portalındaki VM'nin uzantı dikey penceresinde bildirilen durumdur.

Ayrıca yürütmelerinin ayrıntılı günlüklerini de yazar (örn. " Linux için /var/log/azure/custom-script/handler.log" veya Windows için "C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\CustomScriptHandler.log" ).

VM mevcut bir VM'den yeniden oluşturulursa

Başka bir Azure VM'den gelen özel diske dayalı bir Azure VM oluşturuyor olabilir. Bu durumda, eski VM'de uzantılar olabilir ve bu nedenle ikili dosyalar, günlükler ve durum dosyaları kalır. Yeni VM modeli, önceki VM'nin uzantı durumlarını fark etmez ve bu uzantılar için yanlış bir durum bildirebilir. Yenisini oluşturmadan önce uzantıları eski VM'den kaldırmanızı ve yeni VM oluşturulduktan sonra bu uzantıları yeniden yüklemenizi kesinlikle öneririz. Aynı durum, mevcut bir Azure VM'sinden genelleştirilmiş bir görüntü oluşturduğunuzda da oluşabilir. Uzantılardan tutarsız durumdan kaçınmak için sizi uzantıları kaldırmaya davet ediyoruz.

Bilinen sorunlar

PowerShell iç veya dış komut olarak tanınmıyor

RunCommand uzantısının çıkışında aşağıdaki hata girişlerini fark edeceksiniz:

RunCommandExtension failed with "'powershell' isn't recognized as an internal or external command,"

Analiz

Uzantılar Yerel Sistem hesabı altında çalıştırıldığından, VM'de RDP yaptığınızda powershell.exe düzgün çalışıyor ancak RunCommand ile çalıştırıldığında başarısız oluyor olabilir.

Çözüm

  • PowerShell'in PATH ortam değişkeninde düzgün listelendiğinden emin olun:
    • Denetim Masası'nı açın
    • Sistem ve Güvenlik
    • Sistem
    • Gelişmiş sekmesi -> Ortam Değişkenleri
  • 'Sistem değişkenleri' altında Düzenle'ye tıklayın ve PowerShell'in PATH ortam değişkeninde olduğundan emin olun (genellikle: "C:\Windows\System32\WindowsPowerShell\v1.0")
  • VM'yi yeniden başlatın veya WindowsAzureGuestAgent hizmetini yeniden başlatın, ardından Çalıştır Komutunu yeniden deneyin.

Komut iç veya dış komut olarak tanınmıyor

C:\WindowsAzure\Logs\Plugins<ExtensionName><Version>\CommandExecution.log dosyasında aşağıdakileri görürsünüz:

Execution Error: '<command>' isn't recognized as an internal or external command, operable program or batch file.

Analiz

Uzantılar Yerel Sistem hesabı altında çalıştırıldığından, VM'de RDP yaptığınızda powershell.exe düzgün çalışıyor ancak RunCommand ile çalıştırıldığında başarısız oluyor olabilir.

Çözüm

  • VM'de bir Komut İstemi açın ve hatayı yeniden oluşturmak için bir komut yürütür. VM Aracısı Yönetici cmd.exe kullanır ve cmd her başlatıldığında yürütülecek önceden yapılandırılmış bir komutunuz olabilir.
  • PATH değişkeninizin yanlış yapılandırılmış olması da olasıdır, ancak bu sorun yaşayan komuta bağlıdır.

VMAccessAgent, Yönetici hesabı için Uzak Masaüstü Bağlantısı ayarları güncelleştirilemiyor ile başarısız oluyor. Hata: System.Runtime.InteropServices.COMException (0x800706D9): Uç nokta eşleyicisinden başka uç nokta yok.

Uzantının durumunda aşağıdakileri görürsünüz:

Type Microsoft.Compute.VMAccessAgent
Version 2.4.8
Status Provisioning failed
Status level Error
Status message Cannot update Remote Desktop Connection settings for Administrator account. Error: System.Runtime.InteropServices.COMException (0x800706D9): There are no more endpoints available from the endpoint mapper. (Exception from HRESULT: 0x800706D9) at NetFwTypeLib.INetFwRules.GetEnumerator() at 
Microsoft.WindowsAzure.GuestAgent.Plugins.JsonExtensions.VMAccess.RemoteDesktopManager.EnableRemoteDesktopFirewallRules() 
at Microsoft.WindowsAzure.GuestAgent.Plugins.JsonExtensions.VMAccess.RemoteDesktopManager.EnableRemoteDesktop() at

Analiz

Windows Güvenlik Duvarı hizmeti çalışmadığında bu hata oluşabilir.

Çözüm

Windows Güvenlik Duvarı hizmetinin etkinleştirilip etkinleştirilmediğini ve çalışıp çalışmadığını denetleyin. Değilse, lütfen etkinleştirin ve başlatın. Ardından VMAccessAgent'ı çalıştırmayı yeniden deneyin.

Doğrulama yordamına göre uzak sertifika geçersiz.

WaAppAgent.log aşağıdakileri görürsünüz

System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.
Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

Analiz

VM'nizde büyük olasılıkla "Güvenilen Kök Sertifika Yetkilileri" içinde Baltimore CyberTrust Kök sertifikası eksiktir.

Çözüm

certmgr.msc ile sertifikalar konsolunu açın ve sertifikanın orada olup olmadığını denetleyin.

Diğer bir olası sorun, sertifika zincirinin ZScaler gibi bir üçüncü taraf SSL Denetleme aracı tarafından bozulmasıdır. Bu tür bir araç, SSL incelemesini atlayacak şekilde yapılandırılmalıdır.