استكشاف مشكلات إدارة التحديثات وإصلاحها

  • مقالة

تنبيه

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

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

إشعار

إذا واجهت مشاكل عند نشر إدارة التحديث على جهاز Windows، فافتح عارض الأحداث Windows، وتحقق من سجل أحداث Operations Manager ضمن سجلات التطبيقات والخدمات على الجهاز المحلي. ابحث عن الأحداث ذات معرف الحدث 4502 وتفاصيل الحدث التي تحتوي على Microsoft.EnterpriseManagement.HealthService.AzureAutomation.HybridAgent.

السيناريو: يظهر تحديث Windows Defender دائما على أنه مفقود

المشكلة

يظهر تحديث التعريف ل Windows Defender (كيلوبايت 2267602) دائما على أنه مفقود في التقييم عند تثبيته ويظهر محدثا عند التحقق منه من محفوظات Windows Update.

السبب

يتم نشر تحديثات التعريف عدة مرات في اليوم الواحد. ونتيجة لذلك، يمكنك مشاهدة إصدارات متعددة من KB2267602 المنشورة في يوم واحد؛ ولكن مع معرف تحديث وإصدار مختلفين.

يعمل تحديث تقييم الإدارة مرة واحدة خلال 11 ساعة. في هذا المثال، تم إجراء تقييم في الساعة 10:00 صباحًا، وكان الإصدار 1.237.316.0 متوفرًا في ذلك الوقت. عند البحث في جدول التحديث في مساحة عمل Log Analytics، يتم عرض تحديث التعريف 1.237.316.0 مع UpdateState of Needed. إذا تم تشغيل نشر مجدول بعد بضع ساعات، فلنفترض أن الساعة 1:00 مساء والإصدار 1.237.316.0 لا يزال متوفرا أو إصدار أحدث مثبتا، ويتم تثبيت الإصدار الأحدث وينعكس هذا في السجل المكتوب في جدول UpdateRunProgress . ومع ذلك، في جدول التحديث ، سيظل يعرض الإصدار 1.237.316.0 حسب الحاجة حتى يتم تشغيل التقييم التالي. عند تشغيل التقييم مرة أخرى، قد لا يكون هناك تحديث تعريف أحدث متوفر، لذلك لن يعرض جدول التحديث إصدار تحديث التعريف 1.237.316.0 على أنه مفقود أو إصدار أحدث متوفر حسب الحاجة. وبسبب تكرار تحديثات التعريف، قد تكون هناك إصدارات متعددة يتم إرجاعها في بحث السجل.

نوع الحل

يتم الإبلاغ بتشغيل استعلام السجل التالي؛ لتأكيد تحديثات التعريف المثبتة بشكل صحيح. يقوم هذا الاستعلام بإرجاع الوقت الذي تم إنشاؤه وإصداره وتحديث معرف كيلوبايت 2267602 في جدول التحديثات. استبدل قيمة الكمبيوتر باسم الجهاز المؤهل بالكامل.

Update
| where TimeGenerated > ago(14h) and OSType != "Linux" and (Optional == false or Classification has "Critical" or Classification has "Security") and SourceComputerId in ((
    Heartbeat
    | where TimeGenerated > ago(12h) and OSType =~ "Windows" and notempty(Computer)
    | summarize arg_max(TimeGenerated, Solutions) by SourceComputerId
    | where Solutions has "updates"
    | distinct SourceComputerId))
| summarize hint.strategy=partitioned arg_max(TimeGenerated, *) by Computer, SourceComputerId, UpdateID
| where UpdateState =~ "Needed" and Approved != false and Computer == "<computerName>"
| render table

يجب أن تُرجع نتائج الاستعلام شيئًا مشابهًا لما يلي:

مثال يوضح نتائج استعلام السجل من جدول التحديثات.

قم بتشغيل استعلام السجل التالي للحصول على الوقت الذي تم إنشاؤه وإصداره وتحديث معرف كيلوبايت 2267602 في جدول التحديثات RunProgress. يساعدنا هذا الاستعلام على فهم ما إذا كان قد تم تثبيته من Update Management، أو إذا كان مثبتًا تلقائيًا على الجهاز من Microsoft Update. تحتاج إلى استبدال قيمة CorrelationId بمعرف GUID لمهمة دفتر التشغيل (أي قيمة الخاصية MasterJOBID من مهمة دفتر تشغيل Patch-MicrosoftOMSComputer ) للتحديث، وS sourceComputerId بمعرف GUID للجهاز.

UpdateRunProgress
| where OSType!="Linux" and CorrelationId=="<master job id>" and SourceComputerId=="<source computer id>"
| summarize arg_max(TimeGenerated, Title, InstallationStatus) by UpdateId
| project TimeGenerated, id=UpdateId, displayName=Title, InstallationStatus

يجب أن تُرجع نتائج الاستعلام شيئًا مشابهًا لما يلي:

مثال يوضح نتائج استعلام السجل من جدول التحديثات RunProgress.

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

السيناريو: تظهر تحديثات Linux على أنها معلقة وتلك المثبتة تختلف

المشكلة

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

السبب

عند إجراء تقييم لتحديثات نظام التشغيل المعلقة لجهاز Linux الخاص بك، يتم استخدام ملفات لغة الثغرات الأمنية والتقييم المفتوحة (OVAL) التي يوفرها مورد توزيعة Linux من قبل إدارة التحديث للتصنيف. يتم تصنيف تحديثات Linux ك Security أو Others، استنادا إلى ملفات OVAL التي تنص على التحديثات التي تعالج مشكلات الأمان أو الثغرات الأمنية. ولكن عند تشغيل جدول التحديث، فإنه يعمل على جهاز Linux باستخدام إدارة الحزمة المناسبة؛ مثل: YUM، أو APT، أو ZYPPER لتثبيته. قد يتضمن مدير الحزم في توزيعة نظام التشغيل Linux آلية مختلفة لتصنيف التحديثات، حيث قد تختلف النتائج عن النتائج التي تم الحصول عليها من ملفات OVAL بواسطة إدارة التحديث.

نوع الحل

يمكنك التحقق يدويًا من جهاز Linux، والتحديثات المعمول بها، وتصنيفها لكل مدير حزمة توزيعة. لفهم التحديثات التي يصنفها مدير الحزمة على أنها Security ، قم بتشغيل الأوامر التالية.

بالنسبة إلى YUM، يقوم الأمر التالي بإرجاع قائمة غير صفرية من التحديثات المصنفة على أنها Security by Red Hat. لاحظ أنه في حالة CentOS، فإنه يقوم بإرجاع قائمة فارغة دائمًا، ولا يحدث أي تصنيف أمان.

sudo yum -q --security check-update

بالنسبة إلى ZYPPER، يقوم الأمر التالي بإرجاع قائمة غير صفرية بالتحديثات المصنفة على أنها Security by SUSE.

sudo LANG=en_US.UTF8 zypper --non-interactive patch --category security --dry-run

بالنسبة إلى APT، يقوم الأمر التالي بإرجاع قائمة غير صفرية من التحديثات المصنفة على أنها Security بواسطة Canonical for Ubuntu Linux distros.

sudo grep security /etc/apt/sources.list > /tmp/oms-update-security.list LANG=en_US.UTF8 sudo apt-get -s dist-upgrade -oDir::Etc::Sourcelist=/tmp/oms-update-security.list

من هذه القائمة، يمكنك تشغيل الأمر grep ^Inst للحصول على جميع تحديثات الأمان المعلقة.

السيناريو: تتلقى الخطأ "فشل تمكين حل التحديث"

المشكلة

عند محاولة تمكين Update Management في حساب Automation الخاص بك، تحصل على الخطأ التالي:

Error details: Failed to enable the Update solution

السبب

يمكن أن يحدث هذا الخطأ للأسباب التالية:

  • قد لا يتم تكوين متطلبات جدار حماية شبكة الاتصال لعامل "تحليلات السجل" بشكل صحيح. يمكن أن يؤدي هذا الموقف إلى فشل العامل عند حل عناوين URL DNS.

  • يتم تكوين استهداف Update Management بشكل خاطئ، ولا يتلقى الجهاز تحديثات كما هو متوقع.

  • قد تلاحظ أيضا أن الجهاز يعرض حالة ضمن Non-compliantالتوافق. في الوقت نفسه، يقوم سطح مكتب المندوب Analytics بالإبلاغ عن العامل على أنه Disconnected.

نوع الحل

  • قم بتشغيل مستكشف الأخطاء ومصلحها لنظام التشغيل Windows أو Linux، اعتمادا على نظام التشغيل.

  • انتقل إلى تكوين الشبكة للتعرف على العناوين والمنافذ التي يجب السماح بها لكي تعمل إدارة التحديث.

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

  • قم بإزالة تكوين العامل باتباع الخطوات الواردة في إزالة Hybrid Runbook Worker من كمبيوتر Windows محلي أو إزالة Hybrid Runbook Worker من كمبيوتر Linux محلي.

السيناريو: تحديث تم استبداله مشار إليه بأنه مفقودة في Update Management

المشكلة

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

السبب

لا يتم رفض التحديثات التي تم استبدالها في Windows Server Update Services (WSUS)؛ بحيث يمكن اعتبارها غير قابلة للتطبيق.

نوع الحل

عندما يصبح التحديث الذي تم تغييره غير قابل للتطبيق بنسبة 100 بالمائة، يجب تغيير حالة الموافقة على هذا التحديث إلى Declined في WSUS. لتغيير حالة الموافقة على كافة التحديثات:

  1. في حساب التنفيذ التلقائي، حدد إدارة التحديث لعرض حالة الجهاز. راجع عرض تقييمات التحديث.

  2. تحقق من التحديث الذي تم استبداله للتأكد من أنه غير قابل للتطبيق تمامًا.

  3. على خادم WSUS، تقوم الأجهزة بالإبلاغ عن رفض التحديث.

  4. حدد أجهزة الكمبيوتر ، وفي عمود التوافق ، قم بفرض إعادة المسح للتوافق. راجع إدارة تحديثات للأجهزة الظاهرية.

  5. كرر الخطوات أعلاه للحصول على تحديثات أخرى تم استبدالها.

  6. بالنسبة إلى خادم Windows Server Update Services (WSUS)، قم بتنظيف جميع التحديثات التي تم تغييرها لتحديث البنية الأساسية باستخدام معالج تنظيف خادم WSUS.

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

السيناريو: لا تظهر الأجهزة في المدخل ضمن إدارة التحديث

المشكلة

تحتوي الأجهزة على الأعراض التالية:

  • يظهر Not configured جهازك من طريقة عرض إدارة التحديث لجهاز ظاهري.

  • الأجهزة مفقودة من طريقة عرض Update Management لحساب Azure Automation.

  • لديك أجهزة تظهر على أنها Not assessed ضمن التوافق. ومع ذلك، تشاهد بيانات نبضات القلب في سجلات Azure Monitor لعامل دفتر التشغيل المختلط؛ ولكن ليس لـ Update Management.

السبب

يمكن أن يكون سبب هذه المشكلة هو مشكلات التكوين المحلي، أو تكوين نطاق تكوين بشكل غير صحيح. الأسباب المحددة المحتملة هي:

  • قد تضطر إلى إعادة تسجيل وإعادة تثبيت عامل دفتر التشغيل المختلط.

  • ربما قمت بتعريف حصة نسبية في مساحة العمل التي تم الوصول إليها، مما يمنع تخزين البيانات بشكل أكبر.

نوع الحل

  1. قم بتشغيل مستكشف الأخطاء ومصلحها لنظام التشغيل Windows أو Linux، اعتمادا على نظام التشغيل.

  2. تأكد من أن الجهاز الخاص بك يقوم بتقديم تقارير إلى مساحة العمل الصحيحة. للحصول على إرشادات حول كيفية التحقق من هذا الجانب، راجع التحقق من اتصال العامل ب Azure Monitor. تأكد أيضًا من أن مساحة العمل هذه مرتبطة بحساب Azure Automation. للتأكيد، انتقل إلى حساب التنفيذ التلقائي وحدد Linked workspace (مساحة عمل مرتبطة) ضمن Related Resources (الموارد المرتبطة).

  3. تأكد من أن الأجهزة تظهر في مساحة عمل Log Analytics المرتبطة بحساب Automation. تشغيل الاستعلام التالي في مساحة عمل Log Analytics.

    Heartbeat
| summarize by Computer, Solutions

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

    إذا كان جهازك مدرجا في نتائج الاستعلام، فتحقق ضمن خاصية الحلول من إدراج التحديثات . يتحقق هذا من أنه مسجل مع Update Management. إذا لم يكن كذلك، فتحقق من وجود مشكلات في تكوين النطاق. يحدد تكوين النطاق الأجهزة التي تم تكوينها لإدارة التحديث. لتكوين تكوين النطاق للهدف الجهاز، راجع تمكين الأجهزة في مساحة العمل.

  4. في مساحة العمل الخاصة بك، قم بتشغيل هذا الاستعلام.

    Operation
| where OperationCategory == 'Data Collection Status'
| sort by TimeGenerated desc

    إذا كنت تحصل على نتيجة ⁦Data collection stopped due to daily limit of free data reached. Ingestion status = OverQuota⁩، فقد تم الوصول إلى الحصة النسبية المحددة على مساحة العمل الخاصة بك، والتي أوقفت حفظ البيانات. في مساحة العمل الخاصة بك، انتقل إلى إدارة حجم البيانات ضمن الاستخدام والتكاليف المقدرة، وقم بتغيير الحصة النسبية أو إزالتها.

  5. إذا كانت المشكلة الخاصة بك لا تزال دون حل، فاتبع الخطوات في ⁦⁩نشر عامل سجل تشغيل مختلط لـ Windows⁦⁩ لإعادة تثبيت عامل مختلط لـ Windows. بالنسبة إلى Linux، اتبع الخطوات في ⁦⁩نشر عامل سجل التشغيل المختلط لـ Linux⁦⁩.

السيناريو: غير قادر على تسجيل موفر موارد التنفيذ التلقائي للاشتراكات

المشكلة

عند العمل مع عمليات نشر الميزات في حساب Automation، يحدث الخطأ التالي:

Error details: Unable to register Automation Resource Provider for subscriptions

السبب

لم يتم تسجيل موفر موارد Automation في الاشتراك.

نوع الحل

لتسجيل موفر موارد Automation اتبع الخطوات التالية في المدخل Azure.

  1. في قائمة خدمة Azure في أسفل المدخل، حدد All services، ثم حدد Subscriptions في مجموعة الخدمة العامة.

  2. حدد Subscription الخاص بك.

  3. ضمن الإعدادات، حدد موفرو الموارد.

  4. من قائمة موفري الموارد، تحقق من أن يتم تسجيل موفر الموارد Microsoft.Automation.

  5. إذا لم يكن مدرجا، فسجل موفر Microsoft.Automation باتباع الخطوات الواردة في حل الأخطاء لتسجيل موفر الموارد.

السيناريو: لم يقم التحديث المجدول بتصحيح بعض الأجهزة

المشكلة

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

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

السبب

يمكن أن يكون لهذه المشكلة أحد الأسباب التالية:

  • لم يتم تكوين الاشتراكات المعرفة في النطاق في استعلام حيوي لموفر موارد Automation المسجل.

  • لم تكن الأجهزة متوفرة، أو لم يكن لديها علامات مناسبة عند تنفيذ الجدول الزمني.

  • ليس لديك حق الوصول الصحيح على النطاقات المحددة.

  • لا يقوم الاستعلام Azure Resource Graph باسترداد الأجهزة المتوقعة.

  • لم يتم تثبيت عامل دفتر التشغيل المختلط للنظام على الأجهزة.

نوع الحل

الاشتراكات التي لم يتم تكوينها لموفر موارد Automation المسجل

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

  1. في مدخل Microsoft Azure، قم بالوصول إلى قائمة خدمة Azure.

  2. حدد All services، ثم حدد Subscriptions في مجموعة الخدمات العامة.

  3. ابحث عن الاشتراك المحدد في نطاق النشر.

  4. ضمن الإعدادات، اختر موفرو الموارد.

  5. تحقق من أن يتم تسجيل موفر موارد Microsoft.Automation.

  6. إذا لم يكن مدرجا، فسجل موفر Microsoft.Automation باتباع الخطوات الواردة في حل الأخطاء لتسجيل موفر الموارد.

الأجهزة غير متوفرة أو غير معلمة بشكل صحيح عند تنفيذ الجدول

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

  1. في مدخل Microsoft Azure، افتح حساب التنفيذ التلقائي وحدد Update Management.

  2. تحقق من محفوظات إدارة التحديث لتحديد الوقت الدقيق الذي تم فيه تشغيل نشر التحديث.

  3. بالنسبة للأجهزة التي تشك في أنها فائتة من قبل إدارة التحديث، استخدم Azure Resource Graph (ARG) لتحديد موقع تغييرات الجهاز.

  4. البحث عن التغييرات على مدى فترة طويلة، مثل يوم واحد، قبل تشغيل نشر التحديث.

  5. تحقق من نتائج البحث عن أي تغييرات نظامية، مثل حذف أو تحديث التغييرات، على الأجهزة في هذه الفترة. يمكن لهذه التغييرات تغيير حالة الجهاز أو علاماته؛ بحيث لا يتم تحديد الأجهزة في قائمة الجهاز عند نشر التحديثات.

  6. ضبط الأجهزة وإعدادات الموارد حسب الضرورة لتصحيح حالة الجهاز أو مشكلات العلامة.

  7. أعد تشغيل جدول التحديث؛ للتأكد من أن النشر مع المجموعات الحيوية المحددة يتضمن كافة الأجهزة.

الوصول غير الصحيح على النطاقات المحددة

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

استعلام Resource Graph لا يرجع الأجهزة المتوقعة

اتبع الخطوات التالية لمعرفة ما إذا كانت الاستعلامات تعمل بشكل صحيح.

  1. تشغيل استعلام Azure Resource Graph منسق كما هو موضح أدناه في جزء مستكشف Resource Graph في مدخل Azure. إذا كنت مستخدما جديدا ل Azure Resource Graph، فشاهد هذا التشغيل السريع لمعرفة كيفية العمل مع مستكشف Resource Graph. يحاكي هذا الاستعلام عوامل التصفية التي حددتها عند إنشاء المجموعة الحيوية في Update Management. راجع استخدام المجموعات الديناميكية مع إدارة التحديث.

    where (subscriptionId in~ ("<subscriptionId1>", "<subscriptionId2>") and type =~ "microsoft.compute/virtualmachines" and properties.storageProfile.osDisk.osType == "<Windows/Linux>" and resourceGroup in~ ("<resourceGroupName1>","<resourceGroupName2>") and location in~ ("<location1>","<location2>") )
| project id, location, name, tags = todynamic(tolower(tostring(tags)))
| where  (tags[tolower("<tagKey1>")] =~ "<tagValue1>" and tags[tolower("<tagKey2>")] =~ "<tagValue2>") // use this if "All" option selected for tags
| where  (tags[tolower("<tagKey1>")] =~ "<tagValue1>" or tags[tolower("<tagKey2>")] =~ "<tagValue2>") // use this if "Any" option selected for tags
| project id, location, name, tags

    إليك مثال:

    where (subscriptionId in~ ("20780d0a-b422-4213-979b-6c919c91ace1", "af52d412-a347-4bc6-8cb7-4780fbb00490") and type =~ "microsoft.compute/virtualmachines" and properties.storageProfile.osDisk.osType == "Windows" and resourceGroup in~ ("testRG","withinvnet-2020-01-06-10-global-resources-southindia") and location in~ ("australiacentral","australiacentral2","brazilsouth") )
| project id, location, name, tags = todynamic(tolower(tostring(tags)))
| where  (tags[tolower("ms-resource-usage")] =~ "azure-cloud-shell" and tags[tolower("temp")] =~ "temp")
| project id, location, name, tags

  2. تحقق لمعرفة ما إذا كانت الأجهزة التي تبحث عنها مدرجة في نتائج الاستعلام.

  3. إذا لم يتم سرد الأجهزة، فمن المحتمل أن تكون هناك مشكلة في عامل التصفية المحدد في المجموعة الحيوية. ضبط تكوين المجموعة حسب الحاجة.

عامل دفتر التشغيل المختلط غير مثبت على الأجهزة

تظهر الأجهزة في Azure Resource Graph نتائج الاستعلام؛ ولكنها لا تظهر في معاينة المجموعة الحيوية. في هذه الحالة، قد لا يتم تعيين الأجهزة كعاملين في نظام دفتر التشغيل المختلط، وبالتالي لا يمكن تشغيل وظائف إدارة الأتمتة، وتحديث Azure. لضمان إعداد الأجهزة التي تتوقع رؤيتها كعاملين في نظام التشغيل المختلط:

  1. في المدخل Azure، انتقل إلى حساب Automation لجهاز لا يظهر بشكل صحيح.

  2. حدد مجموعات Hybrid worker ضمن Automation.

  3. حدد علامة التبويب System hybrid worker groups.

  4. التحقق من وجود العامل المختلط لهذا الجهاز.

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

    يعتمد الأسلوب الخاص بالتمكين على البيئة التي يعمل بها الجهاز.

  6. كرر الخطوات أعلاه لكافة الأجهزة التي لم يتم عرضها في المعاينة.

السيناريو: تمكين مكونات إدارة التحديث، بينما يستمر الجهاز الظاهري في الظهور على أنه تم تكوينه

المشكلة

يمكنك الاستمرار في مشاهدة الرسالة التالية على الجهاز الظاهري بعد بدء النشر بـ 15 دقيقة:

The components for the 'Update Management' solution have been enabled, and now this virtual machine is being configured. Please be patient, as this can sometimes take up to 15 minutes.

السبب

يمكن أن يحدث هذا الخطأ للأسباب التالية:

  • يتم حظر الاتصال مع حساب Automation.

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

  • قد تأتي صورة الجهاز الظاهري التي يتم نشرها من جهاز مستنسخ لم يتم إعداده مع إعداد النظام (sysprep) مع عامل Log Analytics Windows الذي تم تثبيته.

نوع الحل

للمساعدة في تحديد المشكلة الدقيقة بالجهاز الظاهري، قم بتشغيل الاستعلام التالي في مساحة عمل Log Analytics المرتبطة بحساب Automation الخاص بك.

Update
| where Computer contains "fillInMachineName"
| project TimeGenerated, Computer, SourceComputerId, Title, UpdateState

تم حظر الاتصال بحساب Automation

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

قم بتكرار اسم الكمبيوتر

قم بإعادة تسمية الأجهزة الظاهرية الخاص بك؛ لضمان أسماء فريدة في البيئة الخاصة بها.

صورة منشورة من جهاز مستنسخ

إذا كنت تستخدم صورة مستنسخة، فإن أسماء أجهزة الكمبيوتر المختلفة لها نفس معرف الكمبيوتر المصدر. في هذه الحالة:

  1. في مساحة عمل Log Analytics، قم بإزالة الجهاز الظاهري من البحث المحفوظ لتكوين MicrosoftDefaultScopeConfig-Updates النطاق إذا تم عرضه. يمكن العثور على عمليات البحث المحفوظة ضمن عام في مساحة العمل الخاصة بك.

  2. قم بتشغيل أمر cmdlet التالي.

    Remove-Item -Path "HKLM:\software\microsoft\hybridrunbookworker" -Recurse -Force

  3. قم بتشغيل Restart-Service HealthService لإعادة تشغيل الخدمة الصحية. تؤدي هذه العملية إلى إعادة إنشاء المفتاح، وإنشاء UUID جديد.

  4. إذا لم تنجح هذه الطريقة، فقم بتشغيل sysprep على الصورة أولاً، ثم قم بتثبيت عامل سجل Analytics Windows.

السيناريو: تتلقى خطأ اشتراك مرتبط عند إنشاء نشر تحديث للأجهزة في مستأجر Azure آخر

المشكلة

تواجه الخطأ التالي عند محاولة إنشاء نشر تحديث للأجهزة في مستأجر Azure آخر:

The client has permission to perform action 'Microsoft.Compute/virtualMachines/write' on scope '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/resourceGroupName/providers/Microsoft.Automation/automationAccounts/automationAccountName/softwareUpdateConfigurations/updateDeploymentName', however the current tenant '00000000-0000-0000-0000-000000000000' is not authorized to access linked subscription '00000000-0000-0000-0000-000000000000'.

السبب

يحدث هذا الخطأ عند إنشاء نشر تحديث يحتوي على الأجهزة الظاهرية Azure في مستأجر آخر مضمن في نشر تحديث.

نوع الحل

استخدم الحل البديل التالي للحصول على هذه العناصر المجدولة. يمكنك استخدام New-AzAutomationSchedule cmdlet مع المعلمة ForUpdateConfiguration لإنشاء جدول زمني. ثم استخدم الأمر cmdlet New-AzAutomationSoftwareUpdateConfiguration وقم بتمرير الأجهزة في المستأجر الآخر إلى المعلمة NonAzureComputer . يبين المثال التالي كيفية القيام بذلك:

$nonAzurecomputers = @("server-01", "server-02")

$startTime = ([DateTime]::Now).AddMinutes(10)

$s = New-AzAutomationSchedule -ResourceGroupName mygroup -AutomationAccountName myaccount -Name myupdateconfig -Description test-OneTime -OneTime -StartTime $startTime -ForUpdateConfiguration

New-AzAutomationSoftwareUpdateConfiguration  -ResourceGroupName $rg -AutomationAccountName $aa -Schedule $s -Windows -AzureVMResourceId $azureVMIdsW -NonAzureComputer $nonAzurecomputers -Duration (New-TimeSpan -Hours 2) -IncludedUpdateClassification Security,UpdateRollup -ExcludedKbNumber KB01,KB02 -IncludedKbNumber KB100

السيناريو: عمليات إعادة التشغيل غير المفسرة

المشكلة

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

السبب

يمكنه تعديل Windows Update بواسطة عدة مفاتيح تسجيل، والتي يمكن لأي منها تعديل سلوك إعادة التشغيل.

نوع الحل

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

السيناريو: يعرض الجهاز "فشل البدء" في نشر التحديث

المشكلة

جهاز يعرض الحالة Failed to start أو Failed . عند عرض تفاصيل معينة للجهاز، راجع الخطأ التالي:

For one or more machines in schedule, UM job run resulted in either Failed or Failed to start state. Guide available at https://aka.ms/UMSucrFailed.

السبب

يمكن أن يحدث هذا الخطأ لأحد الأسباب التالية:

  • الآلة لم تعد موجودة بعد الآن.
  • تم إيقاف تشغيل الجهاز، ولا يمكن الوصول إليه.
  • الجهاز لديه مشكلة في اتصال شبكة الاتصال، وبالتالي العامل المختلط على الجهاز غير قابل للوصول.
  • كان هناك تحديث إلى عامل Log Analytics الذي غير معرف الكمبيوتر المصدر.
  • تم إعاقة تشغيل التحديث الخاص بك إذا وصلت إلى الحد الأقصى لـ 200 مهمة متزامنة في حساب Automation. يعتبر كل توزيع مهمة، ويتم احتساب كل جهاز في نشر تحديث كوظيفة. أي مهمة أتمتة أخرى، أو تحديث النشر قيد التشغيل حاليًا في حساب التنفيذ الخاص بك تحسب نحو حد المهمة المتزامنة.

نوع الحل

يمكنك استرداد مزيدٍ من التفاصيل برمجيًا باستخدام API REST. راجع تشغيل جهاز تكوين تحديث البرامج للحصول على معلومات حول استرداد قائمة بتشغيل جهاز تكوين التحديث أو جهاز تكوين تحديث برنامج واحد يتم تشغيله بواسطة المعرف.

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

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

السيناريو: يتم تثبيت التحديثات دون نشر

المشكلة

عند تسجيل جهاز Windows في Update Management، تشاهد التحديثات المثبتة بدون نشر.

السبب

في Windows، يتم تثبيت التحديثات تلقائيًا بمجرد توفرها. يمكن أن يسبب هذا السلوك الارتباك إذا لم تقم بجدولة تحديث ليتم نشرها على الجهاز.

نوع الحل

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU يتم تعيين مفتاح التسجيل افتراضيا إلى إعداد 4: auto download and install.

بالنسبة لعملاء Update Management، نوصي بتعيين هذا المفتاح إلى 3: auto download but do not auto install.

لمزيد من المعلومات، راجع تكوين التحديثات التلقائي.

⁧⁩⁧⁩السيناريو: الجهاز مسجل بالفعل لحساب مختلف

المشكلة

تتلقى رسالة الخطأ التالية:

Unable to Register Machine for Patch Management, Registration Failed with Exception System.InvalidOperationException: {"Message":"Machine is already registered to a different account."}

السبب

تم بالفعل نشر الجهاز إلى مساحة عمل أخرى لـ Update Management.

نوع الحل

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

السيناريو: لا يمكن للجهاز الاتصال بالخدمة

المشكلة

تتلقى إحدى رسائل الخطأ التالية:

Unable to Register Machine for Patch Management, Registration Failed with Exception System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a receive. ---> System.ComponentModel.Win32Exception: The client and server can't communicate, because they do not possess a common algorithm

Unable to Register Machine for Patch Management, Registration Failed with Exception Newtonsoft.Json.JsonReaderException: Error parsing positive infinity value.

The certificate presented by the service <wsid>.oms.opinsights.azure.com was not issued by a certificate authority used for Microsoft services. Contact your network administrator to see if they are running a proxy that intercepts TLS/SSL communication.

Access is denied. (Exception form HRESULT: 0x80070005(E_ACCESSDENIED))

السبب

قد يقوم وكيل أو بوابة أو جدار حماية بحظر اتصال الشبكة.

نوع الحل

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

السيناريو: غير قادر على إنشاء شهادة موقعة ذاتيا

المشكلة

تتلقى إحدى رسائل الخطأ التالية:

Unable to Register Machine for Patch Management, Registration Failed with Exception AgentService.HybridRegistration. PowerShell.Certificates.CertificateCreationException: Failed to create a self-signed certificate. ---> System.UnauthorizedAccessException: Access is denied.

السبب

تعذر على عامل دفتر التشغيل المختلط إنشاء شهادة موقعة ذاتيًا.

نوع الحل

تحقق من أن حساب النظام لديه حق الوصول للقراءة إلى المجلد C:\ProgramData\Microsoft\Crypto\RSA ، وحاول مرة أخرى.

السيناريو: فشل التحديث المجدول مع خطأ MaintenanceWindowExceeded

المشكلة

نافذة الصيانة الافتراضية للتحديثات هي 120 دقيقة. يمكنك زيادة نافذة الصيانة إلى 6 ساعات كحد أقصى، أو 360 دقيقة. قد تتلقى رسالة الخطأ For one or more machines in schedule, UM job run resulted in Maintenance Window Exceeded state. Guide available at https://aka.ms/UMSucrMwExceeded.

نوع الحل

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

يمكنك استرداد مزيدٍ من التفاصيل برمجيًا باستخدام API REST. راجع تشغيل جهاز تكوين تحديث البرامج للحصول على معلومات حول استرداد قائمة بتشغيل جهاز تكوين التحديث أو جهاز تكوين تحديث برنامج واحد يتم تشغيله بواسطة المعرف.

قم بتحرير أي فشل نشرات التحديث المجدولة، وزيادة إطار الصيانة.

لمزيد من المعلومات حول نوافذ الصيانة، راجع تثبيت التحديثات.

السيناريو: يظهر الجهاز على أنه "لم يتم تقييمه" ويعرض استثناء HRESULT

المشكلة

  • لديك أجهزة تظهر على أنها Not assessed ضمن التوافق، وتشاهد رسالة استثناء أسفلها.
  • راجع رمز خطأ HRESULT في المدخل.

السبب

لم يتم تكوين عامل التحديث بشكل صحيح (عامل تحديث Windows على Windows؛ مدير الحزم لتوزيع Linux). تعتمد Update Management على عامل التحديث الخاص بالجهاز لتوفير التحديثات المطلوبة، وحالة التصحيح، ونتائج التصحيحات المنشورة. بدون هذه المعلومات، لا يمكن لخدمة Update Management تقديم تقرير عن التصحيحات المطلوبة أو المثبتة بشكل ملائم.

نوع الحل

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

تحدث هذه المشكلة بشكل متكرر بسبب تكوين شبكة الاتصال، ومشكلات جدار الحماية. استخدم الشبكات التالية لتصحيح المشكلة.

  • بالنسبة إلى Linux، تحقق من الوثائق المناسبة؛ للتأكد من أنه يمكنك الوصول إلى نقطة نهاية الشبكة في مستودع الحزمة.

  • بالنسبة إلى Windows، تحقق من تكوين العامل كما هو مدرج في التحديثات لا يتم تنزيله من نقطة نهاية الإنترانت (WSUS/SCCM) .

    • إذا تم تكوين الأجهزة ل Windows Update، فتأكد من أنه يمكنك الوصول إلى نقاط النهاية الموضحة في المشكلات المتعلقة ب HTTP/proxy.
    • إذا تم تكوين الأجهزة خادم Windows Server Update Services (WSUS)، فتأكد من أنه يمكنك الوصول إلى خادم WSUS الذي تم تكوينه بواسطة مفتاح التسجيل WUServer.

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

الاستثناء الحل أو الإجراء
Exception from HRESULT: 0x……C ابحث في رمز الخطأ ذي الصلة في قائمة رمز الخطأ Windows update للعثور على تفاصيل إضافية حول سبب الاستثناء.
0x8024402C
0x8024401C
0x8024402F		 تشير هذه إلى مشكلات في الاتصال بالشبكة. تأكد من أن جهازك لديه اتصال شبكي بـ Update Management. راجع قسم تخطيط الشبكة للحصول على قائمة بالمنافذ والعناوين المطلوبة.
0x8024001E لم تكتمل عملية التحديث بسبب إيقاف تشغيل الخدمة أو النظام.
0x8024002E تم تعطيل خدمة تحديث Windows.
0x8024402C إذا كنت تستخدم خادم WSUS، فتأكد من أن قيم التسجيل ل WUServer وضمن WUStatusServerHKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate مفتاح التسجيل تحدد خادم WSUS الصحيح.
0x80072EE2 هناك مشكلة في اتصال الشبكة، أو مشكلة في التحدث إلى خادم WSUS مكوَّن. تحقق من إعدادات WSUS، وتأكد من إمكانية الوصول إلى الخدمة من العميل.
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it. (Exception from HRESULT: 0x80070422) تأكد من تشغيل خدمة تحديث Windows، (wuauserv)، وعدم تعطيلها.
0x80070005 يمكن أن يحدث خطأ في الوصول المرفوض بسبب أي مما يلي:
الكمبيوتر المصاب
إعدادات Windows Update غير مكونة بشكل صحيح
خطأ في إذن الملف مع مجلد %WinDir%\SoftwareDistribution
مساحة قرص غير كافية على محرك أقراص النظام (C:).
أي استثناء عام آخر قم بتشغيل بحث على الإنترنت؛ للحصول على الحلول الممكنة، والعمل مع دعم تكنولوجيا المعلومات المحلي.

يمكن أن تساعدك مراجعة ملف ٪Windir٪\Windowsupdate.log أيضا في تحديد الأسباب المحتملة. لمزيد من المعلومات حول كيفية قراءة السجل، راجع كيفية قراءة ملف Windowsupdate.log.

يمكنك أيضا تنزيل مستكشف أخطاء Windows Update ومصلحها وتشغيله للتحقق من وجود أي مشكلات في Windows Update على الجهاز.

إشعار

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

السيناريو: تشغيل التحديث يعيد حالة الفشل (Linux)

المشكلة

تشغيل التحديث يبدأ؛ ولكنه يواجه أخطاء أثناء التشغيل.

السبب

الأسباب المحتملة:

  • مدير الحزمة غير صحي.
  • سوء تكوين عامل التحديث (WUA لـ Windows، مدير حزمة خاصة بتوزيعة محددة Linux).
  • تتداخل حزم معينة مع التصحيح المستند إلى سحابة.
  • لا يمكن الوصول إلى الجهاز.
  • كان للتحديثات تبعيات لم يتم حلها.

نوع الحل

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

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

إذا لم تتمكن من حل مشكلة تصحيح، فقم بعمل نسخة من ملف /var/opt/microsoft/omsagent/run/automationworker/omsupdatemgmt.log واحتفظ به لأغراض استكشاف الأخطاء وإصلاحها قبل بدء نشر التحديث التالي.

لم يتم تثبيت التصحيحات

لا تقوم الأجهزة بتثبيت التحديثات

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

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

أعرف أن التحديثات متوفرة؛ ولكنها لا تظهر كما هي متوفرة على أجهزتي

يحدث هذا غالبا إذا تم تكوين الأجهزة للحصول على تحديثات من WSUS أو Microsoft Configuration Manager ولكن WSUS و Configuration Manager لم يوافقا على التحديثات.

يمكنك التحقق لمعرفة ما إذا كانت الأجهزة قد تم تكوينها ل WSUS وSCCM عن طريق الرجوع UseWUServer المتقاطع إلى مفتاح التسجيل إلى مفاتيح التسجيل في قسم تكوين التحديثات التلقائي عن طريق تحرير السجل من هذه المقالة.

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

Update | where UpdateState == "Needed" and ApprovalSource == "WSUS" and Approved == "False" | summarize max(TimeGenerated) by Computer, KBID, Title

تظهر التحديثات كما تم تثبيتها؛ ولكن لا يمكنني العثور عليها على الجهاز

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

تثبيت التحديثات حسب التصنيف على Linux

نشر التحديثات على Linux حسب التصنيف ("التحديثات الحرجة والأمنية") له محاذير مهمة، خاصة بالنسبة لـ CentOS. يتم توثيق هذه القيود في صفحة نظرة عامة على إدارة التحديث.

KB2267602 مفقود باستمرار

كيلوبايت 2267602 هو تحديث تعريف Windows Defender. يتم تحديثه يوميًا.

الخطوات التالية

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

  • احصل على إجابات من الخبراء في Azure من خلال منتديات Azure.
  • تواصل مع @AzureSupport، حساب Microsoft Azure الرسمي لتحسين التجربة الخاصة بالعملاء.
  • احفظ ملفًا يتضمن حادث دعم Azure. انتقل إلى موقع دعم Azure وحدد Get Support.