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

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

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

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

في هذه المقالة سوف نتعرف على استكشاف بعض حالات فشل ملحق الجهاز الظاهري الشائعة وإصلاحها.

‏‫ملاحظة‬

جرب مساعدة VM للحصول على تشخيصات أسرع. نوصي بتشغيل مساعدة VM لويندوز أو VM Assist لنظام لينكس. تساعدك أدوات التشخيص المستندة إلى البرنامج النصي هذه على تحديد المشكلات الشائعة التي تؤثر على عامل ضيف جهاز Azure الظاهري وسلامة الجهاز الظاهري بشكل عام.

إذا كنت تواجه مشاكل في الأداء مع الأجهزة الافتراضية، قبل التواصل مع الدعم، قم بتشغيل هذه الأدوات.

عرض حالة الإضافة

يمكن تنفيذ قوالب 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 وإصلاحها لجهاز Windows الظاهري
• أستكشاف أخطاء عامل Azure Linux وإصلاحها لجهاز ظاهري يعمل بنظام Linux

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

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

عرض حالة الإضافة

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

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

أو أمر CLI:x

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

أو في مدخل Microsoft Azure، عن طريق الاستعراض إلى VM Blade / الإعدادات / الملحقات. يمكنك بعد ذلك النقر فوق الإضافة والتحقق من حالتها ورسالتها.

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

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

‏‫ملاحظة‬

في المستقبل ، سيتم تحسين هذه الوظيفة لإزالة الحاجة إلى إلغاء تثبيت الامتداد.

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

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

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

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

قد ترى أن الملحق لا يعمل لأن "منشئ شهادة Windows Azure CRP" مفقود. تساعد هذه الشهادة في حماية إعدادات الملحق أثناء النقل. يتم إعادة إنشاء هذه الشهادة تلقائيا عن طريق إعادة تشغيل عامل ضيف Windows من داخل الجهاز الظاهري:

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

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

مدخل Microsoft Azure:

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

Azure PowerShell (استبدل اسم RG واسم الجهاز الظاهري بقيمك):

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

Azure CLI (استبدل اسم RG واسم الجهاز الظاهري بقيمك):

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 إلى معالج الملحق من خلال عامل الجهاز الظاهري (على سبيل المثال: "/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 أو في شفرة ملحق الجهاز الظاهري في مدخل Microsoft Azure.

كما يكتبون سجلات مفصلة لتنفيذها (مثال: "var/log/azure/Microsoft.Azure.Extensions.CustomScript/handler.log" لإصدار CSE Linux 2.1.16+، "/var/log/azure/custom-script/handler.log" لإصدارات CSE القديمة من لينكس، أو "C:\WindowsAzure\Logs\Plugins\Microsoft.Compute.CustomScriptExtension\1.10.12\CustomScriptHandler.log" لويندوز).

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

قد يحدث أنك تقوم بإنشاء جهاز 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.

تحليل

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

الحل

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

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