لماذا لا تُنفَّذ مهامّ Task Scheduler أو تنتهي بالرمز 0x1 ── تشخيص الأسباب وتصميم تشغيل آمن

«أريد تشغيل سكربت التجميع الذي أنشأته بـ PowerShell كلّ صباح عند الساعة 6»، «يعمل عند التشغيل يدويّاً، لكنّه لا يعمل عند تحميله على Task Scheduler». عند تلقّي استشارات حول أتمتة الأعمال، ينتهي الأمر تقريباً دائماً بهذا الحديث.

في هذه المدوّنة أيضاً، تناولنا مواضيع الأتمتة تباعاً: أتمتة تنظيم السجلّات، واختبار السكربتات عبر Pester، وتنفيذ PowerShell من C#، وأتمتة الأعمال عبر Power Automate. جميع هذه المقالات تفترض في النهاية «التشغيل الدوريّ عبر Task Scheduler». لكن Task Scheduler نفسه آليّة ذات طبائع غريبة أكثر ممّا يُتوقَّع، وحوادث من نوع «يعمل يدويّاً لكن يفشل في التشغيل الدوريّ» أو «توقّف دون أن يلاحظ أحد» لا تنقطع.

في هذا المقال، نرتّب الأجزاء من آليّة Task Scheduler التي ترتبط مباشرةً بحوادث التشغيل ── حساب التشغيل ونوع تسجيل الدخول، وتشخيص حالة «عدم التنفيذ»، والسبب النمطيّ لقيمة الإرجاع 0x1، وطريقة حفظ السجلّات، والتحكّم في التشغيل المتعدّد ── بالترتيب الذي يكثر التعثّر فيه في العمل الفعليّ.

مقدّمات هذا المقال

1. الخلاصة أوّلاً

• معظم مشاكل Task Scheduler لا تنشأ من السكربت نفسه، بل من عدم فهم «كمن، وفي أيّ جلسة يُنفَّذ». بمجرّد اختيار «التشغيل بغضّ النظر عن تسجيل دخول المستخدم»، صمِّم على افتراض أنّه يعمل في عالم مختلف تماماً عن الجلسة التفاعليّة وبيئة تسجيل الدخول.¹
• تحقيق حالة «عدم التنفيذ» ينطلق من علامة تبويب السجلّ (History) وسجلّ الأحداث (Event Log). لكن سجلّ المهمّة معطَّل افتراضيّاً، لذا يجب تفعيل «تفعيل سجلّ جميع المهامّ» قبل التشغيل الفعليّ.²
• الرمز 0x1 الذي يظهر في «نتيجة التشغيل الأخيرة» ليس خطأً من Task Scheduler، بل يعني أنّ البرنامج الذي تمّ تشغيله أعاد رمز خروج قيمته 1. السبب في جانب السكربت، لذا صمِّم رمز الخروج وابنِ آليّة لحفظ السجلّ بنفسك أوّلاً.³
• الصيغة الأساسيّة لاستدعاء سكربت PowerShell هي -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "المسار الكامل"، مع بناء المسارات داخل السكربت على $PSScriptRoot. هناك أيضاً فخّ كلاسيكيّ وهو عدم جواز وضع علامات اقتباس في حقل «البدء (اختياريّ)».
• لتفادي حادثة توقّف المهمّة صامتة بسبب تغيير كلمة المرور، لا بدّ من تصميم حساب التشغيل (جرد حسابات الخدمة، والنظر في gMSA لبيئة النطاق).⁴
• التحكّم في التشغيل المتعدّد (الافتراضيّ هو «عدم بدء نسخة جديدة»)، وحدّ مدّة التنفيذ (الافتراضيّ 3 أيّام)، وشرط الطاقة (الافتراضيّ AC فقط)، كلّها إعدادات نموذجيّة يستمرّ التشغيل بها على قيمها الافتراضيّة دون أن يُلاحَظ. حدِّدها صراحةً عند التسجيل دائماً.⁵

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 19، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. بنية Task Scheduler ── المشغِّل والعمليّة والشروط والإعدادات

تتكوّن مهمّة Task Scheduler من 4 عناصر رئيسيّة.

يمكن تصدير المهمّة المُنشَأة عبر الواجهة الرسوميّة (taskschd.msc) كملفّ XML. إن أردتَ إدارة تعريف المهمّة عبر Git، أو توزيع نفس المهمّة على عدّة أجهزة، يُنصَح بجعلها سكربتاً عبر تصدير XML مع schtasks /Create /XML، أو عبر وحدة PowerShell ScheduledTasks (New-ScheduledTaskAction / New-ScheduledTaskTrigger / New-ScheduledTaskSettingsSet / Register-ScheduledTask).⁵

$action   = New-ScheduledTaskAction -Execute 'pwsh.exe' `
    -Argument '-NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Jobs\Cleanup-Logs.ps1"' `
    -WorkingDirectory 'C:\Jobs'
$trigger  = New-ScheduledTaskTrigger -Daily -At '06:00'
# القيمة الافتراضيّة لشرط الطاقة هي «البدء فقط عند التشغيل بالطاقة الكهربائيّة (AC) والتوقّف عند التحوّل إلى البطاريّة».
# إذا كانت المهمّة ستعمل أيضاً على حاسوب محمول أو جهاز ميدانيّ، اسمح بذلك صراحةً هنا
$settings = New-ScheduledTaskSettingsSet -StartWhenAvailable `
    -MultipleInstances IgnoreNew `
    -ExecutionTimeLimit (New-TimeSpan -Hours 2) `
    -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries
# استقبل بيانات الاعتماد عبر Get-Credential حتى لا تظهر كلمة المرور على الشاشة
$cred = Get-Credential -UserName 'DOMAIN\svc-batch' -Message 'بيانات اعتماد حساب التنفيذ'
Register-ScheduledTask -TaskName 'KS-Cleanup-Logs' `
    -Action $action -Trigger $trigger -Settings $settings `
    -User $cred.UserName -Password $cred.GetNetworkCredential().Password

إذا أصبح تعريف المهمّة شيفرة، يمكن نقل ما جُرِّب على جهاز التحقّق إلى الإنتاج كما هو، وتتجنّب حالة «لا نعرف بأيّ إعداد يعمل».

لنشر على عدّة أجهزة، تصدير مهمّة أُنجزت في الواجهة الرسوميّة إلى XML وتوزيعها بـ schtasks أسلوب له سوابق أيضاً.

rem تصدير المهمّة التي صُنعت على جهاز التحقّق
schtasks /Query /TN "KS-Cleanup-Logs" /XML > KS-Cleanup-Logs.xml

rem الاستيراد على كلّ جهاز (حدِّد حساب التشغيل وكلمة المرور عند التسجيل)
schtasks /Create /TN "KS-Cleanup-Logs" /XML KS-Cleanup-Logs.xml /RU DOMAIN\svc-batch /RP *

يتضمّن XML المشغِّلات والشروط والإعدادات كلّها، فإيداعه في المستودع يتيح مراجعة تعريف المهمّة وإدارة الفروقات. بالمقابل، تسجيل المهمّة نفسها يدوياً عبر الواجهة على 10 أجهزة يولّد حتماً «مهمّة شاردة» بإعداد مختلف على جهاز واحد. أمّن الأمر بتحويله إلى شيفرة قبل أن يصبح العدد منزلتين.

3. حساب التشغيل ونوع تسجيل الدخول ── أكبر نقطة حوادث

خيارا خصائص المهمّة «التشغيل فقط عند تسجيل دخول المستخدم» و«التشغيل بغضّ النظر عن تسجيل دخول المستخدم» هما داخليّاً اختيار نوع تسجيل الدخول (LogonType). إن انحرف الفهم هنا، تضلّ عن تفسير معظم «يعمل يدوياً ولا يعمل دوريّاً».¹

3.1 الفرق بين الأوضاع الثلاثة

الحوادث النمطيّة في العمل كالتالي.

• سُجِّل سكربت يصل إلى مجلّد مشترك بـ «عدم حفظ كلمة المرور» (S4U). عمل في الاختبار المحلّي، وفي الإنتاج فشل الوصول إلى المجلّد المشترك وحده. ← لأنّ S4U لا يملك بيانات اعتماد للشبكة.
• بعد أشهر من التسجيل بـ «التشغيل بغضّ النظر عن تسجيل الدخول» حلّ أجل كلمة مرور النطاق فغُيِّرت. بعد ذلك توقّفت المهمّة بفشل تسجيل الدخول (0x8007052E) دون أن يلاحظ أحد.
• سُجِّلت مهمّة تشغّل تطبيقاً بواجهة رسوميّة بـ «بغضّ النظر». التطبيق يعمل لكن الشاشة لا تظهر في أيّ مكان، فيُظنّ أنّه «لا يعمل». ← لأنّه يعمل في جلسة غير تفاعليّة. المعالجة التي تحتاج شاشة تفاعليّة لا تعمل بهذا التكوين من حيث المبدأ.

كذلك، الحساب الذي يعمل بـ Password / S4U يحتاج حقّ «تسجيل الدخول كمهمة دُفعيّة» (SeBatchLogonRight). يُمنح لـ Administrators افتراضيّاً، لكن عند جعل مستخدم عاديّ مخصّص حساب خدمة راجع أيضاً إعداد سياسة الأمان المحلّيّة.⁶

3.2 بأيّ حساب نُشغِّل؟

• SYSTEM: لا يحتاج إدارة كلمة مرور وهو قويّ، لكنّ الصلاحيّات أقوى من اللازم. مفيد لمعالجة صيانة محلّيّة مكتملة، لكن تجنّب جعل SYSTEM لكلّ مهمّة تلمس بيانات أعمال. فكرة متى تلزم فعلاً صلاحيات المسؤول مرتَّبة في مقال منفصل: «متى يصبح Windows admin privilege ضرورياً - UAC والمناطق المحميّة وكيفيّة التمييز على مستوى التصميم».
• حساب خدمة مخصّص (مستخدم عاديّ): يمكن تضييق الصلاحيّات إلى الحدّ الأدنى، مقابل حاجة إلى تحديث المهمّة عند كلّ تغيير لكلمة المرور. أدِر أجل كلمة المرور وجرد المهامّ معاً.
• gMSA (حساب خدمة مُدار جماعيّاً): الخيار الأوّل في بيئة النطاق. يدير المتحكّم بالنطاق كلمة المرور تلقائيّاً، فتختفي مشكلة «المهمّة تموت عند تغيير كلمة المرور» أصلاً. يدعم Task Scheduler التشغيل بـ gMSA.⁴

مربّع «التشغيل بأعلى الامتيازات» يعني التشغيل برمز المسؤول (المُرقَّى) من الرمزين اللذين يقسمهما UAC. لا تضعْه لمهمّة لا تحتاج صلاحيات مسؤول.

3.3 الحدّ الأدنى لتسجيل مهمّة بـ gMSA

ما دمنا سمّينا gMSA «الخيار الأوّل»، نبيّن أيضاً كيف يُسجَّل فعلاً. مهامّ Task Scheduler مذكورة رسميّاً كأحد التكوينات التي تدعم gMSA.⁴

الشروط المسبقة كالتالي.⁴

• مستوى وظائف النطاق والغابة Windows Server 2012 فما بعده
• إنشاء مفتاح جذر KDS في النطاق (يمكن تأكيد الإنشاء بحدث المعرِّف 4004 في سجلّ Operational لـ KdsSvc)
• إنشاء gMSA وإدارته لأعضاء Domain Admins أو Enterprise Admins
• اسم gMSA فريد على مستوى الغابة لا النطاق. وجود الاسم نفسه في نطاق آخر يفشل الإنشاء

الخطوات ثلاث. ينفّذ 1 و2 مسؤول النطاق، و3 على كلّ جهاز ستعمل عليه المهمّة.

# --- 1. جانب النطاق: إنشاء gMSA. حدِّد بالمجموعة الأمنيّة المضيفات المسموح لها بجلب كلمة المرور ---
#     ضع في <SecurityGroup> مجموعة تضمّ حسابات أجهزة الخوادم التي ستشغّل المهمّة
New-ADServiceAccount -Name 'svc-batch' -DNSHostName 'svc-batch.contoso.local' `
    -PrincipalsAllowedToRetrieveManagedPassword 'GG-BatchHosts'

# --- 2. على كلّ جهاز تشغّل عليه المهمّة: ثبِّت gMSA وتحقّق من إمكان جلب كلمة المرور ---
Install-ADServiceAccount -Identity 'svc-batch'
Test-ADServiceAccount   -Identity 'svc-batch'   # إن عاد True فهو جاهز

الخطوة الثالثة هي تسجيل المهمّة. النقطتان هما التاليتان.

# --- 3. على الجهاز الذي تشغّل عليه المهمّة: سجِّل المهمّة وgMSA هو الـ principal ---
$action  = New-ScheduledTaskAction -Execute 'pwsh.exe' `
    -Argument '-NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Jobs\Cleanup-Logs.ps1"' `
    -WorkingDirectory 'C:\Jobs'
$trigger = New-ScheduledTaskTrigger -Daily -At '06:00'

# النقطة 1: ألحق $ في نهاية اسم الحساب (صيغة اسم gMSA)
# النقطة 2: LogonType هو Password. لكن لا تمرِّر -Password
#            (يدير المتحكّم بالنطاق كلمة مرور gMSA ويجلبها المضيف)
$principal = New-ScheduledTaskPrincipal -UserId 'CONTOSO\svc-batch$' `
    -LogonType Password -RunLevel Limited

Register-ScheduledTask -TaskName 'KS-Cleanup-Logs' `
    -Action $action -Trigger $trigger -Principal $principal

القيم التي يمكن تحديدها في -LogonType لـ New-ScheduledTaskPrincipal هي None / Password / S4U / Interactive / Group / ServiceAccount / InteractiveOrPassword.⁷ كما في جدول القسم 3.1، لا يصل S4U إلى موارد الشبكة، فلا تختره بسهولة لمهمّة تلمس مجلّداً مشتركاً.

تكميلان. أولاً، هذا gMSA يحتاج أيضاً حقّ «تسجيل الدخول كمهمة دُفعيّة» (الكلام نفسه في نهاية القسم 3.1؛ gMSA لا يُعفى).⁶ ثانياً، schtasks.exe أمر يفترض تمرير كلمة مرور حساب التشغيل بـ /RP، وإجراء التسجيل بـ gMSA غير موجَّه رسميّاً. عند استخدام gMSA اجمع تسجيل المهمّة على جانب PowerShell Register-ScheduledTask. إن جمعته مع أسلوب الفصل 2 «تصدير XML والتوزيع بـ schtasks»، يصبح التكوين استبدال جزء الـ principal فقط عبر PowerShell.

4. خطوات تشخيص «لا تُنفَّذ»

4.1 فعِّل السجلّ ثم اشبه

«تفعيل سجلّ جميع المهامّ» في الجزء الأيمن من Task Scheduler معطَّل افتراضيّاً. إن بقي السجلّ معطَّلاً لا يبقى حتى سجلّ بوقوع الفشل. فعِّله حتماً قبل التشغيل الفعليّ. الخطوات كالتالي.

1. شغِّل Task Scheduler (taskschd.msc، أو ابحث في قائمة ابدأ عن «Task Scheduler»). شغِّله بصلاحيات مسؤول.
2. في شجرة الجزء الأيسر اختر الأعلى «Task Scheduler (Local)». لن يظهر هذا البند إن كانت مهمّة فرديّة محدَّدة.
3. انقر «Enable All Tasks History» في قائمة «Actions» في الجزء الأيمن. إن كان مفعَّلاً أصلاً، يتغيّر العرض إلى «Disable All Tasks History».

كيان السجلّ هو سجلّ Applications and Services Logs > Microsoft > Windows > TaskScheduler > Operational في عارض الأحداث.² علامة تبويب «History» لكلّ مهمّة تعرض هذا السجلّ مصفّى بالمهمّة المستهدَفة، لذا لتتبّع التسلسل الزمنيّ عبر عدّة مهامّ افتح جانب عارض الأحداث.

خطوات التشخيص الأساسيّة تعمل كما هي وفق دليل استكشاف الأخطاء لدى Microsoft.²

1. اختبر السكربت منفرداً ── قبل التحميل على المهمّة، تأكّد أنّ السكربت نفسه يكتمل بشروط حساب التشغيل نفسها (إن أمكن بـ runas أو جهاز تحقّق).
2. انظر عمود الحالة وعلامة تبويب السجلّ ── ميّز هل أُطلق المشغِّل أصلاً، أم بدأ ثم فشل. إن لم يُطلق، اشبه إعداد المشغِّل والشروط (الطاقة والشبكة)، وتحقّق هل تعمل العمليّة نفسها بالتشغيل اليدويّ (نقر أيمن ← Run).
3. جرِّب التحويل المؤقّت إلى «التشغيل فقط عند تسجيل الدخول» ── إن عمل بذلك، ينحصر السبب في الجلسة غير التفاعليّة أو بيانات الاعتماد (الفصل السابق).

4.2 ماذا تشبه إذا ظهر ماذا في علامة تبويب السجلّ ── جدول سريع لمعرِّفات الأحداث

كلّ سطر في علامة تبويب السجلّ (وسجلّ Operational) يحمل معرِّف حدث. بهذا المعرِّف تعرف فوراً «إلى أين وصل». المهمّة الطبيعيّة الواحدة تتراتب تقريباً: «بدء (100) ← تشغيل العمليّة (129) ← بدء العمليّة (200) ← اكتمال العمليّة (201) ← اكتمال (102)».

أبرز ثلاث قراءات هي التالية.

• إن غاب 100 فانظر أولاً هل ظهر 101 (تعذّر بدء المهمّة). إن ظهر، أُطلق المشغِّل وفشل التشغيل، فاشبه قيمة الخطأ وحساب التشغيل (الفصل 3). إن غاب 101 أيضاً فالسبب قبل المهمّة (المشغِّل، والشروط، وتعطيل المهمّة)، وإن ظهر 322 فسبب ذلك أنّ النسخة السابقة لم تنتهِ.
• إن وُجد 100 وغاب 102 فقد بدأ ولم ينتهِ. 111 / 329 انتهاء وقت، 203 فشل التشغيل نفسه، و327 / 328 تعني أنّ النسخة قيد التنفيذ أُوقفت بشرط الطاقة أو الخمول (327 / 328 سجلّ «أوقفت» لا «لم تبدأ»، فيظهر بعد 100).
• إن وُجد 100 و102 والنتيجة غريبة فقد أكمل Task Scheduler نطاق مسؤوليّته. بعد ذلك لا يُتتبَّع إلا بسجلّ جانب السكربت (الفصل 6).

flowchart TD
    S["لا تُنفَّذ أو النتيجة غريبة"] --> Q1{"هل يوجد الحدث 100 (بدء)؟"}
    Q1 -->|"لا"| Q1b{"هل يوجد الحدث 101؟"}
    Q1b -->|"نعم"| A0["أُطلق المشغِّل لكن فشل التشغيل. انظر قيمة خطأ 101 وحساب التشغيل (الفصل 3)"]
    Q1b -->|"لا"| A1["السبب قبل المهمّة: المشغِّل والشروط والتعطيل (القسم 4.4). إن كان 322 فالسابقة لم تنتهِ"]
    Q1 -->|"نعم"| Q2{"هل يوجد الحدث 102 (إنهاء طبيعيّ)؟"}
    Q2 -->|"لا"| B["بدأ ولم ينتهِ. 203 = فشل التشغيل نفسه. 111 و329 = انتهاء وقت. 327 و328 = إيقاف بشرط الطاقة أو الخمول. 202 = فشل جانب Task Scheduler"]
    Q2 -->|"نعم"| C["جانب Task Scheduler اكتمل. إن كان 0x1 فالسكربت أعاد رمز خروج 1. بعد ذلك تتبّع بسجلّ السكربت (الفصل 6)"]

الشكل 1: وجود الحدثين 100 و102 أو غيابهما يفصل جهة البحث بين إعداد المهمّة وجانب السكربت.

هنا موضع يسهل الخطأ فيه. حتى لو انتهى البرنامج بقيمة غير صفريّة مثل 0x1، يرى Task Scheduler أنّه «بدأ وانتهى» فيظهر 201 (ACTION_SUCCESS). 202 حدث «تعذّر على Task Scheduler إكمال العمليّة»، وليس وعاءً لانتهاء غير صفريّ للبرنامج.⁹ لذلك قد لا تجد 202 وأنت تتتبّع 0x1. ما ينبغي النظر إليه هو قيمة إرجاع 201 وعمود «نتيجة التشغيل الأخيرة» للمهمّة (القسم 4.3). ResultCode في 201 و«نتيجة التشغيل الأخيرة» لا يتطابقان بالضرورة، فالأوثق تسجيل رمز خروجك بنفسك في جانب السكربت كما في الفصل 6.

4.3 قراءة «نتيجة التشغيل الأخيرة»

سلسلة 0x413xx رموز حالة Task Scheduler، و0x8007xxxx رموز أخطاء Windows، والقيم الصغيرة مثل 0x1 و0x2 هي رمز خروج البرنامج الذي شُغِّل نفسه.³ بهذا التمييز لا تخطئ من البداية جهة البحث (إعداد المهمّة أم السكربت).

flowchart TB
    R["القيمة الظاهرة في «نتيجة التشغيل الأخيرة»"]
    R -->|"قيمة صغيرة مثل 0x0 / 0x1 / 0x2"| P["رمز خروج البرنامج الذي شُغِّل نفسه. جهة البحث هي السكربت"]
    R -->|"0x413xx"| ST["رمز حالة Task Scheduler (انتظار، تنفيذ، لم تُنفَّذ). لا يعبّر عن فشل أصلاً"]
    R -->|"0x8007xxxx"| Q{"هل شُغِّلت العمليّة؟ (هل يوجد 201، وهل غاب 203؟)"}
    Q -->|"لم تُشغَّل"| W["رمز خطأ Windows (تحديد مجلّد البدء غير صحيح، فشل تسجيل الدخول، وغيرها). جهة البحث إعداد المهمّة"]
    Q -->|"شُغِّلت"| W2["رمز خروج أعادته العمليّة الابنة. قد يعيده التطبيق بصيغة HRESULT. جهة البحث هي السكربت"]

الشكل 2: تختلط في العمود نفسه ثلاث سلاسل قيم. غير أنّ 0x8007xxxx لا يُحسَم بالبادئة وحدها ── إن شُغِّلت العمليّة فهي القيمة التي أعادتها العمليّة الابنة، فاحكم المصدر بمقابلة الحدثين 201 و203.

4.4 انتبه للقيم الافتراضيّة للشروط والإعدادات

• شرط الطاقة: افتراضيّاً مفعَّل «بدء المهمّة فقط عند استخدام الحاسوب بطاقة AC». إن جعلت حاسوباً محمولاً جهاز تحقّق، يصبح «عطل لا يتكرّر» يعمل فقط أثناء البطاريّة. علاوة على ذلك، من Windows 10 فصاعداً تتأخّر مشغِّلات كثير من المهامّ أثناء تفعيل ميزة توفير البطاريّة.¹¹
• عند فوات وقت البدء: إن كان الحاسوب مطفأً وتجاوز وقت البدء، لا تُنفَّذ افتراضيّاً حتى الجدول التالي. فعِّل صراحة «إذا تعذّر بدء المهمّة في الوقت المجدوَل، شغِّلها فوراً» (-StartWhenAvailable)، أو قرِّر كتصميم أنّ الفوات مقبول.⁵
• إيقاظ من النوم: لمهمّة ليليّة على حاسوب ينام، قرِّر أيضاً لزوم «إيقاظ الحاسوب لتشغيل المهمّة» (-WakeToRun).

نجمع هنا، حسب علامة التبويب، أين تقع الإعدادات التي ظهرت حتى الآن في الواجهة الرسوميّة. هذا تكوين مربع الحوار الذي يُفتح بنقر أيمن على المهمّة ← «Properties».

4.5 انتبه لتصميم المشغِّل نفسه

قد تظنّ «لا تُنفَّذ» بينما تصميم المشغِّل نفسه منحرف عن القصد.

• «كلّ شهر في اليوم 31» لا يُنفَّذ في الأشهر التي لا تحتوي 31. لمعالجة نهاية الشهر أميل إلى تصميم يقصد «آخر يوم من الشهر» (معالجة حصّة الشهر السابق في أوّله، أو الحكم بالتاريخ داخل السكربت).
• الوقت هو الوقت المحلّي للجهاز الذي سُجِّلت عليه المهمّة. توزيع XML نفسه على أجهزة فروع خارجيّة أو خوادم تُشغَّل أحياناً بتوقيت UTC يزيح وقت التنفيذ حسب الفرع. قرِّر كمواصفة هل المقصود «السادسة صباحاً بتوقيت اليابان في كلّ الفروع» أم «السادسة صباحاً في كلّ فرع».
• إن بدأت التكرار بفاصل قصير (كلّ 5 دقائق مثلاً) عبر Task Scheduler فانتبه. هو أداة ممتازة لـ«دُفعة مرّة في اليوم»، لكن إن لزم استقصاء بالدقيقة أو مراقبة دائمة فذلك مجال عمليّة مقيمة (الفصل 8 لاحقاً).
• مشغِّل الحدث قويّ، لكن تحقّق أولاً أنّ الحدث المستهدَف يُسجَّل بثبات. تكوين يشغِّل بمعرِّف حدث معيّن في سجلّ التطبيق يصمت عن العمل إذا تغيّر أسلوب إصدار الأحداث بعد تحديث التطبيق. مشغِّل وقت + حكم شرط داخل السكربت كثيراً ما يكون أسهل تتبّعاً في النهاية.

5. الأنماط النمطيّة للانتهاء بـ 0x1 والاستدعاء الصحيح لـ PowerShell

0x1 نتيجة فشل السكربت فقط، فالسبب في فرق بيئة تنفيذ السكربت. ما يختلف بين التشغيل اليدويّ والدوريّ هو أساساً التالي.

• دليل العمل الحاليّ مختلف: إن لم تحدِّد «البدء (اختياريّ)» يعمل في C:\Windows\System32 مثلاً. السكربت المكتوب بمسارات نسبيّة ينكسر هنا. ابنِ المسارات في السكربت على $PSScriptRoot، وحدِّد مجلّد العمل في «البدء (اختياريّ)» على جانب المهمّة. عندئذ لا تضع علامات اقتباس في حقل «البدء (اختياريّ)». اكتب حتى المسار الذي يتضمّن مسافات بلا اقتباس (وضعها يفشل بـ 0x8007010B).
• متغيّرات البيئة والملفّ الشخصيّ مختلفة: عدّ متغيّرات البيئة التي يضبطها سكربت تسجيل الدخول أو ملفّ المستخدم الشخصيّ، ومحرّكات الشبكة المرتبطة (مثل X:)، غير موجودة في الجلسة غير التفاعليّة. استخدم مسار UNC (\\server\share\...) مباشرة، وأزل فرق الملفّ الشخصيّ بـ -NoProfile.
• سياسة التنفيذ مختلفة: قد تكون RemoteSigned مضبوطة للمستخدم وغير مضبوطة لحساب الخدمة. صرِّح بـ -ExecutionPolicy Bypass في معطيات المهمّة.
• اتفاقيّة رمز خروج الأداة خاصّة: مثلاً يعيد robocopy القيمة 1 عندما «نُسخت كلّ الملفّات بنجاح». الغلاف الذي يعيد رمز الخروج كما هو يظهر 0x1 رغم الحالة الطبيعيّة، أو العكس. راجع دائماً اتفاقيّة رمز الخروج للأمر الخارجيّ الذي تستخدمه.

في حالة robocopy، جدول رموز الخروج الرسميّ يعدّ 0 إلى 7 تركيبات «بلا فشل»، و8 فما فوق تعني «وقع فشل واحد على الأقلّ أثناء النسخ».¹² أي أنّ الصحيح ليس الإعادة كما هي، بل غلاف يُطبِّع إلى 0/1.

# استقبل المعطيات بنفسك. لا تعتمد ضمنيّاً على متغيّرات جهة الاستدعاء
param(
    [Parameter(Mandatory)][string]$Source,
    [Parameter(Mandatory)][string]$Destination
)

# يعيد robocopy رمز الخروج في $LASTEXITCODE.
# حتى مع $ErrorActionPreference = 'Stop'، الانتهاء غير الصفريّ للأمر الأصليّ
# لا يصبح استثناء، لذا يلزم الحكم بنفسك
robocopy $Source $Destination /E /R:2 /W:5 /NP
$rc = $LASTEXITCODE

if ($rc -ge 8) {
    Write-Error "فشل robocopy. رمز الخروج: $rc"
    exit 1
}

# 0 إلى 7 بلا فشل. اترك ما حدث في السجلّ، وأعد النجاح إلى Task Scheduler
Write-Host "اكتمل robocopy بنجاح. رمز الخروج: $rc"
exit 0

سطر -ge 8 هو الجوهر. إن كتبت if ($rc -ne 0) تُعدّ المرّة التي نُسخ فيها بنجاح (1) فشلاً أيضاً. هذا هو جوهر الاستشارة الكلاسيكيّة «يصل إشعار فشل النسخ الاحتياطيّ كلّ صباح، لكن الملفّات منسوخة فعلاً».

الصيغة الأساسيّة لاستدعاء PowerShell كالتالي.

البرنامج/السكربت:  pwsh.exe          (powershell.exe إن كان Windows PowerShell)
إضافة المعطيات:            -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "C:\Jobs\Cleanup-Logs.ps1"
البدء (اختياريّ):      C:\Jobs           (بلا علامات اقتباس)

سبب استخدام -File لا -Command، فضلاً عن أنّ تهريب المعطيات يصبح مباشراً، أنّ exit n في السكربت يصبح رمز خروج العمليّة كما هو، فيمكن تمييز النجاح من الفشل من «نتيجة التشغيل الأخيرة» في Task Scheduler. صمِّم أيضاً في جانب السكربت إعادة 0 صراحة عند النجاح وغير 0 عند الفشل.

# اضبط Stop حتى تسقط «أخطاء غير منتهية» للأوامر في catch.
# بدونها قد تمرّ إخفاقات مثل Copy-Item وينتهي الأمر بـ exit 0
$ErrorActionPreference = 'Stop'

try {
    Main
    exit 0
}
catch {
    Write-Error $_
    exit 1
}

فكرة أين تُلتقط الاستثناءات وكيف تُسجَّل مفصَّلة أيضاً في مقال منفصل: «أين يجب التقاط الاستثناءات وتسجيلها ومعالجة الأخطاء - دليل عمليّ للحدود والمسؤوليّات في تسلسل الاستدعاء».

6. اترك السجلّ بنفسك

سجلّ Task Scheduler لا يخبرك إلا «هل بدأ، وما رمز الخروج». ما الذي فعله السكربت وإلى أين وصل يلزم أن يتركه السكربت نفسه كسجلّ.

في الحدّ الأدنى، لا تُعد التوجيه في معطيات المهمّة (صيغة التوجيه في حقل «المعطيات» في Task Scheduler لا تعمل لأنّها ليست عبر صدفة)، بل خذ transcript داخل السكربت فهو أيسر.

$logDir = 'C:\Jobs\logs'
New-Item -ItemType Directory -Path $logDir -Force | Out-Null
Start-Transcript -Path (Join-Path $logDir ("cleanup-{0:yyyyMMdd}.log" -f (Get-Date))) -Append
try {
    # المعالجة الأساسيّة
}
finally {
    Stop-Transcript
}

معالجة مشكلة تراكم السجلّات نفسها (إدارة الأجيال والأرشفة) هي تماماً محتوى «تطبيقات PowerShell المتقدّمة ── أتمتة آمنة لتحقيق السجلّات وأرشفتها وإصدار التقارير عنها».

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

# --- عند الإعداد مرّة واحدة، بصلاحيات مسؤول (المثبِّت أو سكربت الإعداد الأوّليّ) ---
if (-not [System.Diagnostics.EventLog]::SourceExists('KS-Jobs')) {
    [System.Diagnostics.EventLog]::CreateEventSource('KS-Jobs', 'Application')
}

# --- جسم المهمّة (يعمل بحساب أدنى صلاحيات) يقوم بالكتابة فقط.
#     قد يطلب SourceExists صلاحيات مسؤول لاستكشاف كلّ السجلّات، فلا تستدعه وقت التنفيذ.
#     التالي مفترض داخل معالج فشل Main (catch) ---
catch {
    $err = $_
    try {
        [System.Diagnostics.EventLog]::WriteEntry('KS-Jobs',
            "Cleanup-Logs failed: $($err.Exception.Message)",
            [System.Diagnostics.EventLogEntryType]::Error, 1001)
    }
    catch {
        # لا تجعل تعذّر الكتابة في السجلّ سبباً لابتلاع الفشل الأصليّ
        Write-Warning "فشل الكتابة إلى سجلّ الأحداث: $_"
    }
    exit 1
}

تكميلان. أولاً، تسجيل مصدر الحدث (CreateEventSource) يحتاج صلاحيات مسؤول. خلط التسجيل في جسم المهمّة يؤدّي عند أوّل فشل في الإنتاج بحساب خدمة أدنى صلاحيات إلى فشل مزدوج: «محاولة التسجيل ترمى استثناء ← الحدث الجوهريّ لا يُكتب». افصل التسجيل إلى جانب الإعداد كما أعلاه، واجعل وقت التنفيذ كتابة فقط. ثانياً، إذا كان محرّك التنفيذ pwsh.exe كما في أمثلة تسجيل المهمّة في هذا المقال، لا تعمل أوامر New-EventLog / Write-EventLog من عصر Windows PowerShell 5.1 (لا يُوجد الأمر فيفشل السكربت كلّه). استدعاء صنف .NET مباشرة كما أعلاه يعمل على 5.1 و7 كليهما.

بعد ذلك، ضع آليّة «تصل إلى شخص عند الفشل» ── إشعاراً بالبريد أو Teams / Slack ── فتتجنّب حادثة «اكتشفنا في الجرد أنّها توقّفت أشهراً». لا تحتاج بنية إشعار معقّدة؛ بضعة أسطر POST إلى Webhook عند الفشل تكفي. بالمقابل «إشعار عند كلّ نجاح» سرعان ما يتوقّف عن القراءة، فاكبح النجاح إلى ملخّص أسبوعيّ تقريباً، واجعل هدف الرصد الفشل و«لم تُنفَّذ» (وقت التشغيل السابق قديم). معيار ما يُكتب في السجلّ مرتَّب أيضاً في «أين يجب التقاط الاستثناءات وتسجيلها ومعالجة الأخطاء».

7. التحكّم في التشغيل المتعدّد والتنفيذ الطويل

ماذا يحدث إن جاء وقت الجدول التالي بينما السابقة ما زالت تطول؟ يُحسَم ذلك بقاعدة «If the task is already running, then the following rule applies» في علامة تبويب الإعدادات، ويقابل في PowerShell -MultipleInstances.⁵

اضبط أيضاً «الوقت حتى الإيقاف» (-ExecutionTimeLimit، افتراضيّ 3 أيّام) على قيمة واقعيّة (نحو 2 إلى 3 أضعاف مدّة التنفيذ المتوقَّعة)، فتتجنّب حادثة عمليّة معلَّقة تجرّ مهمّة الغد معها.⁵

انتبه أنّ ما يحميه IgnoreNew أو Queue هو داخل تعريف المهمّة نفسها فقط. لا يمنع تصادم مهمّة أخرى تستدعي السكربت نفسه، أو تشغيلاً يدويّاً عند معالجة عطل. إن وُجدت مسارات عدّة تلمس المورد نفسه (ملفّ، قاعدة بيانات، نظام خارجيّ)، ضع حصراً أيضاً في جانب السكربت. الأسلوب الثابت هو mutex مسمّى.

$mutex = New-Object System.Threading.Mutex($false, 'Global\KS-Cleanup-Logs')
$acquired = $false
try {
    try {
        $acquired = $mutex.WaitOne(0)
    }
    catch [System.Threading.AbandonedMutexException] {
        # انتهت المهمّة السابقة قسراً وهي ما زالت تملك الـ mutex
        # (تجاوز «الوقت حتى الإيقاف»، وقتل العمليّة، وانقطاع الطاقة، وغيرها).
        # عندئذ لا يعيد WaitOne القيمة false بل يرمي استثناء،
        # وملكيّة الـ mutex انتقلت إلينا. إن سقطت دون التقاطه،
        # تتوقّف كلّ تنفيذات لاحقة هنا ولا تعمل المهمّة بعد ذلك أبداً
        $acquired = $true
        Write-Warning 'انتهى التنفيذ السابق بشكل غير طبيعي. تحقّق من تنظيف العمل المقطوع.'
        # افحص هنا هل بقي ملفّ كُتب إلى المنتصف أو سجلّ ناقص،
        # ثم انتقل إلى المعالجة الأساسيّة
    }

    if (-not $acquired) {
        Write-Warning 'ينتهي لأن مثيلاً آخر قيد التشغيل.'
        exit 0   # إن لم تعدّ «لم تُنفَّذ» فشلاً فـ 0، وإن عدّتها فشلاً فغير 0
    }

    # المعالجة الأساسيّة
}
finally {
    if ($acquired) { $mutex.ReleaseMutex() }
    $mutex.Dispose()
}

AbandonedMutexException استثناء يُعلم أنّ «المالك السابق اختفى دون تحرير»، وعند الرمي تكون الملكيّة قد انتقلت إلينا. لذلك إن أنهيت بـ exit هنا يبقى دون تحرير ويظهر الاستثناء نفسه في المرّة التالية، فتتوقّف المهمّة إلى الأبد. الصحيح التقاطه، والتحقّق من حالة العمل المقطوع، ثم المتابعة.

إلحاق Global\ في بداية الاسم يجعل الحصر يعمل أيضاً بين جلسات مختلفة (مهمّة مستخدم آخر وتشغيل يدويّ مثلاً). قرِّر وفق طبيعة المهمّة هل تنتظر الحصول على القفل (تمرير مهلة إلى WaitOne) أم تتنازل فوراً. وانتبه أنّ الكائن المسمّى بـ Global\ يراه أيّ شخص على الجهاز. على خادم مشترك يسجّل عليه عدّة مستخدمين، إن أُمسك mutex بالاسم نفسه عمداً أو خطأ، تُتخطّى المهمّة إلى الأبد (وتبدو طبيعيّة إن كان exit 0). في تلك البيئة اضبط ACL (MutexSecurity) على الـ mutex لتضييق الحسابات التي يمكنها الحصول عليه، أو على الأقل أركب «تخطّيت لأنّي لم أحصل» على إشعار الفصل السابق وسجلّ الأحداث، حتى ترصد المراقبة تتابع التخطّي. الحصر في التكامل عبر الملفّات مفصَّل في «أساسيات التحكّم الحصري في تكامل الملفّات - أفضل الممارسات لـ file lock والـ claim الذرّي».

8. متى تتوقّف عن Task Scheduler ── الفصل بينه وبين الخدمة المقيمة

Task Scheduler ليس لكلّ شيء. عندما تنمو المتطلّبات، توجد حدود يكون فيها تبديل الآليّة أفضل من مواصلة الاستخدام بالقوّة.

إن بدأت الاستقصاء بـ«مهمّة كلّ 5 دقائق»، تتراكم تكلفة توليد العمليّة وتحميل الوحدات عند كلّ بدء، ويلزم آليّة لإيداع حالة المرّة السابقة في ملفّ وما شابه، فتعيد عمليّاً تنفيذ عمليّة مقيمة مقطَّعة. عند هذه المرحلة، الإقامة بـ Generic Host في .NET وBackgroundService هي المسار المباشر. نمط التنفيذ مشروح في «لماذا نستخدم Generic Host و BackgroundService في تطبيق سطح المكتب».

بالمقابل، تحويل دُفعة شهريّة أو يوميّة إلى خدمة وإدارة مؤقِّت بنفسك مبالغة أيضاً. الخطّ «فاصل التنفيذ بالساعة فما فوق، والمعالجة مستقلّة، وبلا حالة ← Task Scheduler؛ وإن بدأ الخروج عن ذلك فانظر في الإقامة» لا يخطئ كثيراً.

9. قائمة تحقّق قبل التشغيل الفعليّ

يُنصَح بمراجعة البنود التالية واحداً واحداً قبل التسجيل.

• هل تقرّر حساب التشغيل؟ (ألم تختر SYSTEM بالكسل. إن كان نطاقاً هل نظرت في gMSA؟)
• هل فهمت قيود نوع تسجيل الدخول؟ (S4U بلا وصول للشبكة. Password: هل قرّرت التشغيل عند تغيير كلمة المرور؟)
• هل اختبرت السكربت منفرداً بشروط تعادل حساب التشغيل؟
• هل تستدعيه بصيغة -NoProfile -NonInteractive -ExecutionPolicy Bypass -File؟
• هل مسارات داخل السكربت على أساس $PSScriptRoot / UNC؟ (ألا تعتمد على محرّك مرتبط أو مسار نسبيّ؟)
• ألا توجد علامات اقتباس في «البدء (اختياريّ)»؟
• هل صُمِّم رمز الخروج؟ (نجاح 0 / فشل غير 0. هل راجعت اتفاقيّة رمز خروج الأمر الخارجيّ؟)
• هل فُعِّل سجلّ المهمّة؟ هل يوجد سجلّ السكربت نفسه وإشعار فشل؟
• هل ضُبط شرط الطاقة وStartWhenAvailable والتشغيل المتعدّد وحدّ مدّة التنفيذ صراحة؟
• هل حُفظ تعريف المهمّة في المستودع كـ XML أو سكربت PowerShell؟

10. الخلاصة

Task Scheduler ليس «اكتب السكربت وانتهِ»، بل يستقرّ التشغيل فقط بعد تصميم ثلاث مقدّمات: حساب التشغيل، والجلسة، والقيم الافتراضيّة. بالمقابل، إن ثبّت عند التسجيل النقاط الواردة هنا ── اختيار نوع تسجيل الدخول، وتفعيل السجلّ، وتصميم رمز الخروج والسجلّ، والتصريح بالتشغيل المتعدّد وحدّ الوقت ── يقلّ العمل بعد ذلك على نحو مدهش.

«يعمل يدوياً ولا يعمل دوريّاً» سببه شبه المؤكَّد فرق الجلسة والبيئة. قبل العبث بالإعدادات بلا هدف، تحقّق من أين وصل في علامة تبويب السجلّ، وجرِّب خطوات التشخيص في هذا المقال من الأعلى.

مقالات ذات صلة

• تطبيقات PowerShell المتقدّمة ── أتمتة آمنة لتحقيق السجلّات وأرشفتها وإصدار التقارير عنها
• تهيئة اختبارات PowerShell عبر Pester ── الأسلوب العمليّ لجعل سكربتات التشغيل أقلّ عرضةً للكسر
• أتمتة الأعمال باستخدام Power Automate ── الفصل بين التدفّق السحابي وتدفّق سطح المكتب وتصميم معالجة الأخطاء
• متى يصبح Windows admin privilege ضرورياً - UAC والمناطق المحميّة وكيفيّة التمييز على مستوى التصميم

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع مراجعة تصميم أتمتة الأعمال عبر PowerShell وTask Scheduler، ومع استشارات إعادة بناء المهامّ الدوريّة التي «تعمل لكن لا يستطيع أحد إصلاحها».

• الاستشارة التقنيّة ومراجعة التصميم
• تطوير تطبيقات Windows
• التحقيق في الأعطال
• التواصل معنا

روابط مرجعية

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

ما الذي يعنيه الرمز 0x1 الذي يظهر في «نتيجة التشغيل الأخيرة» في Task Scheduler؟

0x1 ليس خطأً من Task Scheduler نفسه، بل يعني أنّ البرنامج الذي تمّ تشغيله أعاد رمز خروج (exit code) قيمته 1. السبب يكمن في جانب السكربت. الفرق النمطيّ بين التشغيل اليدويّ والتشغيل الدوريّ هو دليل العمل الحاليّ (current directory)، ومتغيّرات البيئة والملفّ الشخصيّ (profile)، وسياسة التنفيذ (execution policy). كما يجب الانتباه إلى اتفاقيّات رمز الخروج الخاصّة ببعض الأوامر الخارجيّة، مثل robocopy الذي يُعيد القيمة 1 حتّى في الحالة الطبيعيّة. معرفة الفرق بين رموز 0x413xx التي هي رموز حالة Task Scheduler نفسه، ورموز 0x8007xxxx التي هي رموز أخطاء Windows، تمنعك من البحث في المكان الخطأ.

لماذا يعمل الأمر يدويّاً لكنّه لا يعمل عبر Task Scheduler؟

السبب شبه مؤكَّد أنّه الفرق في حساب التشغيل والجلسة والبيئة. عند اختيار «التشغيل بغضّ النظر عن تسجيل دخول المستخدم»، تعمل المهمّة في جلسة غير تفاعليّة، فلا تكون محرّكات الأقراص الشبكيّة المرتبطة (mapped drives) أو متغيّرات بيئة ملفّ المستخدم الشخصيّ موجودة. علاوة على ذلك، لا يمكن الوصول إلى الموارد على الشبكة عند اختيار «عدم حفظ كلمة المرور» (S4U). خطوات التشخيص الفعّالة هي: التحقّق من علامة تبويب السجلّ (History)، واختبار السكربت منفرداً، والتحويل المؤقّت إلى «التشغيل فقط عند تسجيل الدخول». وبما أنّ سجلّ المهمّة معطَّل افتراضيّاً، يجب تفعيله قبل بدء التشغيل الفعليّ.

ما الطريقة الصحيحة لاستدعاء سكربت PowerShell من Task Scheduler؟

حدِّد pwsh.exe (أو powershell.exe) في حقل البرنامج، والصيغة الأساسيّة للمعطيات هي -NoProfile -NonInteractive -ExecutionPolicy Bypass -File "المسار الكامل". استخدام -File بدلاً من -Command يجعل exit n داخل السكربت هو رمز خروج العمليّة مباشرةً، ما يتيح تمييز النجاح من الفشل. اجعل المسارات داخل السكربت مبنيّة على $PSScriptRoot، ولا تضع علامات اقتباس في حقل «البدء (اختياريّ)» (وضعها يؤدّي إلى الفشل بالرمز 0x8007010B). صمِّم السكربت نفسه بحيث يُعيد صراحةً 0 عند النجاح وقيمة غير صفريّة عند الفشل.

كيف نتجنّب توقّف المهمّة بسبب تغيير كلمة المرور؟

عند التسجيل بخيار «التشغيل بغضّ النظر عن تسجيل الدخول»، تُحفَظ كلمة المرور، فتستمرّ المهمّة بالتوقّف بفشل تسجيل الدخول (0x8007052E) بعد تغيير كلمة المرور. في بيئة النطاق (domain)، يكون الخيار الأوّل هو gMSA (حساب خدمة مُدار جماعيّاً) الذي يدير فيه المتحكّم بالنطاق كلمة المرور تلقائيّاً، وعندها تختفي هذه المشكلة أصلاً. أمّا عند استخدام حساب خدمة مخصَّص، فأدِر مدّة صلاحيّة كلمة المرور وجرد المهامّ معاً. وأضِف كذلك آليّة تُخطِر عبر البريد الإلكترونيّ أو Teams عند الفشل، لتفادي حادثة عدم ملاحظة توقّف المهمّة لعدّة أشهر.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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