استكشاف أخطاء ملحق Azure Windows VM وإصلاحها

نظرة عامة على قوالب Azure Resource Manager

تسمح لك قوالب Azure Resource Manager بتحديد البنية الأساسية Azure IaaS بشكلٍ معلن بلغة JSON من خلال تحديد التبعيات بين الموارد.

راجع تأليف قوالب الإضافات لمعرفة المزيد حول تأليف القوالب لاستخدام الملاحق.

في هذه المقالة سوف نتعرف على استكشاف الأخطاء وإصلاحها لبعض حالات فشل ملحق VM الشائعة.

عرض حالة الملحق

يمكن تنفيذ قوالب Azure Resource Manager من Azure PowerShell. بمجرد تنفيذ القالب، يمكن عرض حالة الملحق من Azure Resource Explorer أو أدوات سطر الأوامر.

وفيما يلي مثال على ذلك:

Azure PowerShell:

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

هذا هو نموذج الإخراج:

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
    }
  ]
}

استكشاف أخطاء الملحق وإصلاحها

تحقق من أن عامل الجهاز الظاهري قيد التشغيل وجاهز

عامل الجهاز الظاهري مطلوب لإدارة تثبيت مُلحقات وتنفيذها. إذا لم يكن عامل الجهاز الظاهري قيد التشغيل أو فشل في الإبلاغ عن حالة جاهز إلى النظام الأساسي Azure، فلن تعمل الملحقات بشكلٍ صحيح.

يرجى الرجوع إلى الصفحات التالية لاستكشاف أخطاء عامل الجهاز الظاهري وإصلاحها:

• استكشاف أخطاء Windows Azure Guest Agent وإصلاحها لجهاز Windows الظاهري
• استكشاف أخطاء عامل Azure Linux لجهاز Linux الظاهري وإصلاحه

تحقق من دليل استكشاف الأخطاء وإصلاحها بالملحق الخاص بك

تحتوي بعض الملحقات على صفحة محددة تصف كيفية استكشاف الأخطاء وإصلاحها. يمكنك العثور على قائمة بهذه الملحقات والصفحات على استكشاف أخطاء الملحقات وإصلاحها.

عرض حالة الملحق

كما هو موضح أعلاه، يمكن العثور على حالة الملحق عن طريق تشغيل cmdlet PowerShell:

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

أو الأمر CLI:

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

أو في مدخل Azure، من خلال الاستعراض إلى جزء الجهاز الظاهري/الإعدادات/الملحقات. يمكنك بعد ذلك النقر فوق الملحق والتحقق من حالته ورسالته.

إعادة تشغيل الملحق على الجهاز الظاهري

إذا كنت تقوم بتشغيل البرامج النصية على الجهاز الظاهري باستخدام ملحق البرنامج النصي المخصص، فقد تواجه أحياناً خطأ حيث تم إنشاء الجهاز الظاهري بنجاح ولكن فشل البرنامج النصي. في ظل هذه الظروف، فإن الطريقة الموصى بها للتعافي من الخطأ هي إزالة الإضافة وإعادة تشغيل القالب مرة أخرى. ملاحظة: في المستقبل، سيتم تحسين هذه الوظيفة لإزالة الحاجة إلى إزالة تثبيت الملحق.

إزالة الملحق من Azure PowerShell

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

بمجرد إزالة الملحق، يمكن إعادة تنفيذ القالب لتشغيل البرامج النصية على الجهاز الظاهري.

تشغيل GoalState جديد إلى الجهاز الظاهري

قد تلاحظ أنه لم يتم تنفيذ ملحق أو فشل في التنفيذ بسبب فقدان "Windows Azure CRP Certificate Generator" (تُستخدم هذه الشهادة لتأمين نقل الإعدادات المحمية للملحق). سيتم إعادة إنشاء هذه الشهادة تلقائياً عن طريق إعادة تشغيل Windows Guest Agent من داخل الجهاز الظاهري:

• فتح إدارة المهام
• الانتقال إلى علامة التبويب "تفاصيل"
• تحديد موقع عملية WindowsAzureGuestAgent.exe
• انقر بزر الماوس الأيمن، وحدد "إنهاء المهمة". سيتم إعادة تشغيل العملية تلقائياً

يمكنك أيضاً تشغيل GoalState جديد إلى الجهاز الظاهري، من خلال تنفيذ "VM Reapply". VM Reapply هي واجهة برمجة تطبيقات تم تقديمها في عام 2020 لإعادة تطبيق حالة الجهاز الظاهري. نوصي بالقيام بذلك في وقت يمكنك فيه تحمل فترة تعطل قصيرة عن العمل في الجهاز الظاهري. على الرغم من أن إعادة التطبيق نفسها لا تتسبب في إعادة تشغيل الجهاز الظاهري، والغالبية العظمى من المرات التي تستدعي فيها إعادة التطبيق لن تعيد تشغيل الجهاز الظاهري، إلا أن هناك خطراً صغيراً جداً يتمثل في تطبيق بعض التحديثات المعلقة الأخرى على نموذج الجهاز الظاهري عندما تؤدي إعادة التطبيق إلى تشغيل حالة هدف جديدة، وقد يتطلب هذا التغيير الآخر إعادة تشغيل.

مدخل Azure:

في المدخل، حدد الجهاز الظاهري وفي الجزء الأيمن ضمن الدعم + استكشاف الأخطاء وإصلاحها، حدد إعادة النشر + إعادة التطبيق، ثم حدد إعادة التطبيق.

Azure PowerShell (استبدل اسم RG واسم VM بقيمك):

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

Azure CLI (استبدل اسم RG واسم VM بقيمك):

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

إذا لم ينجح "إعادة تطبيق الجهاز الظاهري"، فيمكنك إضافة قرص بيانات فارغ جديد إلى الجهاز الظاهري من مدخل إدارة Azure، ثم إزالته لاحقاً بمجرد إضافة الشهادة مرة أخرى.

انظر إلى سجلات الملحق داخل الجهاز الظاهري

إذا لم تنجح الخطوات السابقة وكان الملحق لا يزال في حالة فشل، فإن الخطوة التالية هي الاطلاع على سجلاته داخل الجهاز الظاهري.

على جهاز Windows الظاهري، عادةً ما توجد سجلات الملحقات في

C:\WindowsAzure\Logs\Plugins

وستكون إعدادات الملحق وملفات الحالة في

C:\Packages\Plugins

على جهاز Linux الظاهري، عادةً ما توجد سجلات الملحق في

/var/log/azure/

وستكون إعدادات الملحق وملفات الحالة في

/var/lib/waagent/

يختلف كل ملحق عن الآخر، لكنهم عادة ما يتبعون مبادئ مماثلة:

يتم تنزيل حزم الملحق والثنائيات على الجهاز الظاهري (على سبيل المثال. "/var/lib/waagent/custom-script/download/1" لنظام التشغيل Linux أو "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Downloads\0" لنظام التشغيل Windows).

يتم تمرير تكوينها وإعداداتها من Azure Platform إلى معالج الملحقات من خلال عامل الجهاز الظاهري (على سبيل المثال. "/var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/config" لـ Linux أو "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\RuntimeSettings" لنظام التشغيل Windows)

تقوم معالجات الملحقات داخل الجهاز الظاهري بالكتابة إلى ملف الحالة (على سبيل المثال. "/var/lib/waagent/Microsoft.Azure.Extensions.CustomScript-2.1.3/status/1.status" لنظام التشغيل Linux أو "C:\Packages\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\Status" Windows) والتي سيتم الإبلاغ عنها بعد ذلك إلى النظام الأساسي Azure. هذه الحالة هي الحالة التي تم الإبلاغ عنها من خلال PowerShell أو CLI أو في جزء ملحق الجهاز الظاهري في مدخل Azure.

كما يكتبون سجلات مفصلة للتنفيذ (على سبيل المثال. "/var/log/azure/custom-script/handler.log" لنظام التشغيل Linux أو "C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\CustomScriptHandler.log" لنظام التشغيل Windows).

إذا تمت إعادة إنشاء الجهاز الظاهري من جهاز ظاهري موجود

قد يحدث أنك تقوم بإنشاء جهاز ظاهري Azure استناداً إلى قرص متخصص قادم من جهاز Azure ظاهري آخر. في هذه الحالة، من الممكن أن يحتوي الجهاز الظاهري القديم على ملحقات، وبالتالي سيكون لديه ثنائيات وسجلات وملفات حالة متبقية. لن يكون نموذج الجهاز الظاهري الجديد على دراية بحالات ملحقات الجهاز الظاهري السابقة، وقد يبلغ عن حالة غير صحيحة لهذه الملحقات. نوصيك بشدة بإزالة الملحقات من الجهاز الظاهري القديم قبل إنشاء الجهاز الظاهري الجديد، ثم إعادة تثبيت هذه الملحقات بمجرد إنشاء الجهاز الظاهري الجديد. قد يحدث الشيء نفسه عند إنشاء صورة معممة من جهاز Azure الظاهري الموجود. ندعوك إلى إزالة الملحقات لتجنب حالة عدم الاتساق من الملحقات.

المشكلات المعروفة

لا يتم التعرف على PowerShell كأمر داخلي أو خارجي

لاحظت إدخالات الخطأ التالية في إخراج ملحق RunCommand:

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

التحليل

يتم تشغيل الملحقات ضمن حساب النظام المحلي، لذلك من الممكن جدًا أن يعمل powershell.exe بشكل جيد عند استخدام RDP في الجهاز الظاهري، ولكنه يفشل عند التشغيل باستخدام RunCommand.

حل

• تحقق من إدراج PowerShell بشكل صحيح في متغير بيئة PATH:
  • افتح لوحة التحكم
  • النظام والأمان
  • النظام
  • علامة تبويب متقدمة -> المتغيرات البيئية
• ضمن "متغيرات النظام"، انقر فوق تحرير وتأكد من أن PowerShell في متغير بيئة PATH (عادة: "C:\Windows\System32\WindowsPowerShell\v1.0")
• أعد تشغيل الجهاز الظاهري أو أعد تشغيل خدمة WindowsAzureGuestAgent ثم حاول تشغيل الأمر مرة أخرى.

لا يتم التعرف على الأمر كأمر داخلي أو خارجي

ترى ما يلي في ملف C:\WindowsAzure\Logs\Plugins<ExtensionName><Version>\CommandExecution.log:

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

التحليل

يتم تشغيل الملحقات ضمن حساب النظام المحلي، لذلك من الممكن جدًا أن يعمل powershell.exe بشكل جيد عند استخدام RDP في الجهاز الظاهري، ولكنه يفشل عند التشغيل باستخدام RunCommand.

حل

• افتح موجه الأوامر في الجهاز الظاهري وقم بتنفيذ أمر لإعادة إنتاج الخطأ. يستخدم عامل الجهاز الظاهري cmd.exe المسؤول وقد يكون لديك بعض الأمر الذي تم تكوينه مسبقا للتنفيذ في كل مرة يتم فيها بدء cmd.
• من المحتمل أيضا أن متغير PATH الخاص بك تم تكوينه بشكل خاطئ، ولكن هذا سيعتمد على الأمر الذي تواجه المشكلة.

فشل VMAccessAgent مع يتعذر تحديث إعدادات اتصال سطح المكتب البعيد لحساب المسؤول. خطأ: System.Runtime.InteropServices.COMException (0x800706D9): لا توجد نقاط نهاية إضافية متوفرة من مخطط نقطة النهاية.

ترى ما يلي في حالة الملحق:

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

التحليل

يمكن أن يحدث هذا الخطأ عندما لا تكون خدمة جدار حماية Windows قيد التشغيل.

حل

تحقق مما إذا كان قد تم تمكين خدمة جدار حماية Windows وتشغيلها. إذا لم يكن كذلك، يرجى تمكينه وبدء تشغيله - ثم حاول مرة أخرى لتشغيل VMAccessAgent.

الشهادة البعيدة غير صالحة وفقًا لإجراء التحقق من الصحة.

ترى ما يلي في WaAppAgent.log

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.

التحليل

من المحتمل أن يكون الجهاز الظاهري الخاص بك يفتقد شهادة جذر بالتيمور CyberTrust في "المراجع المصدقة الجذر الموثوق بها".

حل

افتح وحدة تحكم الشهادات باستخدام certmgr.msc، وتحقق مما إذا كانت الشهادة موجودة.

هناك مشكلة أخرى محتملة وهي أن سلسلة الشهادات مقطوعة بواسطة أداة فحص SSL تابعة لجهة خارجية، مثل ZScaler. يجب تكوين هذا النوع من الأدوات لتجاوز فحص SSL.