إدارة تكوين Windows تصريحيّاً بـ DSC ── ابدأ IaC بـ dsc.exe

«أريد إعادة بناء الجهاز القياسي»، «أريد إعادة تشغيل إعداد فشل في المنتصف»، «أريد أن أجد إعداداً غيّره أحدهم يدوياً». حين تدير أجهزة Windows وخوادمها بإجراءات وسكربتات، يظهر العناء في إعادة إنتاج الإعداد نفسه والحفاظ عليه.

إن لم تتعقّب التغييرات بعد التنفيذ، تنحرف الإجراءات عن الواقع. وفي BAT وPowerShell أيضاً، كي لا يحدث تطبيق مزدوج أو خطأ عند إعادة التشغيل، تحتاج أن تكتب بنفسك فحص الوجود والتفرّع. نقل هذا العبء إلى إدارة تكتب «الحالة المرغوبة» لا «الإجراءات» هو DSC (Desired State Configuration).

تتناول هذه المقالة Microsoft DSC v3 (dsc.exe) الذي ظهر عام 2025 أداة سطر أوامر لا تعتمد على PowerShell. هي مدخل لإدارة عملاء Windows والخوادم نفسها بـ IaC تصريحي (Infrastructure as Code)، كما تستخدم Terraform وAnsible على Linux وفي السحابة.¹

الجمهور المطوّرون ومسؤولو نظم المعلومات الذين يريدون نقل إدارة تكوين Windows من الإجراءات والسكربتات. الافتراض Windows 10/11، وDSC 3.0 فما بعده، والعمليات الأساسية في PowerShell، والصعوبة متوسّطة. أسماء المحوّلات في DSC 3.2 فما بعده، وإصدارات WinGet المطلوبة، مشروحة في مواضعها.

1. الخلاصة أوّلاً ── اكتب الحالة، وتأكّد، ثمّ طبّق

إن كنت تبدأ الآن إدارة تكوين Windows تصريحيّاً، فاختر Microsoft DSC v3 (dsc.exe). تكتب «الحالة المرغوبة» في YAML/JSON، وتترك المقارنة بالحالة الحالية والتطبيق لـ DSC والموارد. الأساس إدارة متساوية المفعول: مهما كرّرت تطبيق التكوين نفسه، لا يفعل شيئاً للبنود التي هي أصلاً في الحالة المرغوبة.²³

غير أن «إمكان التطبيق مراراً» و«جواز محتوى التطبيق» أمران مختلفان. اقرأ الحالة أوّلاً، وتأكّد من الفرق والتنبؤ، ثمّ طبّق. كذلك ليس DSC v3 وكيلاً مقيماً، لذا تصمّم التدقيق والإصلاح الدوريّين على حدة.⁴¹

ترتيب القراءة كما يلي.

flowchart TB
    accTitle: من إدارة الإجراءات إلى إدارة الحالة
    accDescr: في سكربت الإجراءات تنفّذ بنفسك فحص الوجود والتفرّع لإعادة التشغيل، أمّا في DSC فتصرّح بالحالة المرغوبة ويتولّى DSC والموارد المقارنة والتطبيق
    imp["كتابة الإجراءات (BAT وPowerShell)"] --> guard["تنفيذ فحص الوجود والتفرّع بنفسك"]
    dec["كتابة الحالة (DSC)"] --> test["المقارنة بالحالة الحالية"]
    test --> set["تطبيق البنود اللازمة فقط"]

الشكل 1: نقل مسؤولية التفكير في إعادة التشغيل من تفريع الإجراءات إلى التصريح بالحالة واستخدام الموارد.

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

2. تمييز DSC الذي تستخدمه ── أربع سلالات، وما ليس في v3

2.1. بطل هذه المقالة هو dsc.exe المستقلّ

البحث عن «DSC» يُخرج معلومات أربع سلالات تختلف في الكتابة وطريقة التشغيل. أكّد أوّلاً أيّ سلالة يعالجها المصدر.⁵

Microsoft DSC v3 ليس مجرّد تحديث لوحدة PowerShell DSC (PSDSC). إنّه منتج آخر أُعيدت كتابته بفصل الاعتماد على PowerShell. تُكتَب التكوين بيانات JSON/YAML، ويمكن تنفيذ الموارد بأيّ لغة. DSC نفسه يعمل على Linux وmacOS وWindows.¹

flowchart TB
    accTitle: نسب سلالات DSC الأربع
    accDescr: من PSDSC v1.1 المضمَّن في Windows PowerShell 5.1 تفرّع PSDSC v2 لـ PowerShell 7 ومعاينة PSDSC v3 لـ Machine Configuration، وبمعزل عنها أُعيدت كتابة Microsoft DSC v3 مستقلّاً عن PowerShell ليصير البطل الحالي
    v11["PSDSC v1.1 (مضمَّن في WinPS 5.1)"] --> v2["PSDSC v2 (PowerShell 7)"]
    v2 --> v3ps["معاينة PSDSC v3"]
    v11 -.->|"إعادة كتابة"| dsc3["Microsoft DSC v3 (dsc.exe)"]
    v3ps --> mc["Azure Machine Configuration"]
    dsc3 --> now["بطل هذه المقالة"]

الشكل 2: حتّى مع الاسم نفسه DSC، ميّز أجيال وحدات PowerShell عن dsc.exe المستقلّ.

«DSC» فيما يلي يعني Microsoft DSC v3. إضافة «DSC v3» و«dsc.exe» إلى عبارة البحث تسهّل فصله عن مصادر الأجيال الأقدم. طريقة استدعاء موارد PSDSC القائمة في الفصل 6.

2.2. v3 ليس خدمة مقيمة تحفظ التكوين وتصلحه تلقائياً

كان LCM (Local Configuration Manager) في PSDSC v1.1 وكيلاً مقيماً يحفظ التكوين ويجري تطبيقاً دورياً وإصلاحاً تلقائياً. ليس لـ DSC v3 LCM؛ هو أمر يعمل فقط عند استدعائه. تثبيت dsc.exe وتطبيق التكوين مرّة لا يعني أنّه سيصلح التغييرات اللاحقة من تلقاء نفسه.¹

flowchart TB
    accTitle: مقابلة نمط LCM المقيم في v1.1 ونمط الأمر في v3
    accDescr: في PSDSC v1.1 تولّى LCM المقيم حفظ التكوين والسحب الدوري والإصلاح التلقائي، أمّا DSC v3 فيُشغَّل أمراً فقط لذا تختار بنفسك بنية التشغيل الدوري من جدولة المهام أو CI أو Machine Configuration
    v1["PSDSC v1.1: LCM مقيم"] --> pull["حفظ التكوين وسحب دوري وإصلاح تلقائي"]
    v3["DSC v3: تشغيل أمري فقط"] --> push["بنية التشغيل تُعدّها بنفسك"]
    push -.-> ex["جدولة المهام وCI وMachine Configuration"]

الشكل 3: في v3 تفصل «كيف تُكوِّن» عن «متى تُشغِّل»، وتوكل الثانية إلى جدولة المهام أو طبقة إدارة أعلى.

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

3. فهم التكوين التصريحي ── مقارنة الإجراءات بالحالة

3.1. أخرج فحص الوجود والتفرّع من التصريح

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

# أمري: تكتب «الإجراءات». تدير بنفسك كلّ التفرّع والترتيب
$path = 'HKCU:\Software\MyCompany\App'
if (-not (Test-Path $path)) {
    New-Item -Path $path -Force | Out-Null
}
Set-ItemProperty -Path $path -Name 'Mode' -Value 'standard'

في DSC تصير المتطلّبات نفسها تصريحاً بالحالة كالتالي. لا تكتب جهة التصريح فحص الوجود ولا تفرّع الإنشاء. المثال الكامل الذي يضع هذه القطعة في resources داخل مستند تكوين يظهر في الفصل 5.

# تصريحي: تكتب «الحالة». خطوات الإنشاء والإصلاح عمل المورد
- name: وضع تشغيل التطبيق
  type: Microsoft.Windows/Registry
  properties:
    keyPath: HKCU\Software\MyCompany\App
    valueName: Mode
    valueData:
      String: standard

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

3.2. المورد يتولّى get وtest وset

المورد في قلب DSC يوفّر العمليات لكلّ هدف تكوين: قيمة سجلّ، ميزة Windows، متغيّر بيئة، وغيرها. يكتب المستخدم «ماذا ينبغي أن يكون»، ويترك «كيف يُضبَط» للمورد.⁶

dsc config set الذي يطبّق التكوين كلّه يختبر كلّ مثيل أوّلاً، ويستدعي set فقط لما ليس في الحالة المرغوبة. هذه آلية إمكان تطبيق التكوين نفسه مراراً.³

flowchart TB
    accTitle: حلقة التقارب عبر get وtest وset
    accDescr: يقارن test الحالة المرغوبة المكتوبة في مستند التكوين بالحالة الحالية، فإن لم يوجد فرق لم يفعل شيئاً، وإن وُجد طبّق set الفرق فقط وأمكن التحقّق من النتيجة بـ get، وهو تدفّق تقارب متساوي المفعول
    doc["مستند التكوين (الحالة المرغوبة)"] --> test["test: مقارنة بالحالة الحالية"]
    test -->|"لا فرق"| ok["لا يفعل شيئاً (متساوي المفعول)"]
    test -->|"هناك فرق"| set["set: تطبيق الفرق فقط"]
    set --> get["get: التحقّق من حالة النتيجة"]

الشكل 4: في تطبيق التكوين كلّه تقارن أوّلاً، ولا تغيّر إلا مثيلات الموارد اللازمة.

3.3. لا تخلط بين resource set المنفرد وconfig set للتكوين كلّه

dsc resource set يستدعي دائماً set للمورد المحدَّد. أمّا الاختبار المسبق فيعتمد على تنفيذ المورد وعلى implementsPretest في البيان. المهم ألّا تفترض أنّ الاختبار المسبق الذي يجريه config set موجود أيضاً في resource set.³

flowchart TB
    accTitle: فرق الاختبار المسبق بين التكوين كلّه والاستدعاء المنفرد
    accDescr: يختبر config set كلّ مثيل ويستدعي set عند الحاجة فقط، أمّا resource set فيستدعي set للمورد دائماً والاختبار المسبق هناك يعتمد على تنفيذ المورد وبيانه
    config["config set"] --> test["اختبار كلّ مثيل"]
    test --> needed{"في الحالة المرغوبة؟"}
    needed -->|"نعم"| skip["لا يستدعي set"]
    needed -->|"لا"| apply["يستدعي set"]
    single["resource set"] --> direct["استدعاء set للمورد"]
    direct -.-> impl["الاختبار المسبق حسب التنفيذ"]

الشكل 5: حتّى مع set نفسه، ميّز عملية التكوين كلّه التي يختبرها DSC مسبقاً عن العملية المنفردة التي تُمرَّر مباشرة إلى المورد.

يسهل الفهم إن فصلت أوّلاً المراقبة بـ get وtest المنفردين، ثمّ التجميع في مستند تكوين حين تدير عدّة حالات. تساوي المفعول خاصّية لإعادة التشغيل؛ لا يلغي نقص الصلاحيات ولا أخطاء تنفيذ المورد.

4. أوّل العمليات ── ثبّت وراقب بـ get وtest

4.1. جهّز dsc.exe وتأكّد من الموارد المتاحة

طريقتا التثبيت: فكّ أرشيف إصدارات GitHub وإضافته إلى PATH، أو التثبيت من winget مع تحديد مصدر Microsoft Store على Windows.¹

# البحث عن الإصدار المستقرّ وتثبيته من مصدر Microsoft Store
winget search DesiredStateConfiguration --source msstore
winget install --id 9NVTPZWRC6KQ --source msstore

بعد التثبيت، اعرض الموارد المتاحة في بيئتك.

dsc resource list

افصل تأكيد تجهيز DSC نفسه عن تأكيد إمكان استخدام المورد الذي تريده. اعثر هنا على اسم النوع المستهدف، ثمّ حدّد الخاصّيات التي تُدخَل. إن استخدمت موارد PSDSC من جيل أقدم، راجع أيضاً محوّلات الفصل 6.

4.2. ابدأ بقراءة سجلّ تحت المستخدم

يمكن استدعاء الموارد واحداً واحداً دون كتابة مستند تكوين. المثال التالي يقرأ قيمة تحت HKCU بـ get، ويحكم بـ test هل هي الحالة المرغوبة. ليست أيّ منهما عملية لتغيير القيمة.⁷

# جلب الحالة الحالية (get)
dsc resource get --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode"}'

# الحكم هل هي الحالة المرغوبة (test) ── بلا أيّ تغيير
dsc resource test --resource Microsoft.Windows/Registry `
  --input '{"keyPath":"HKCU\\Software\\MyCompany\\App","valueName":"Mode","valueData":{"String":"standard"}}'

flowchart TB
    accTitle: العمليات الأربع لأمر dsc resource
    accDescr: تحت أمر dsc resource تتفرّع أربع عمليات: list لعرض الموارد، وget لجلب الحالة الحالية، وtest للحكم هل هي الحالة المرغوبة بلا تغيير، وset للتطبيق (للموارد التي تنفّذ Set فقط)
    cli["أمر dsc resource"] --> l["list: قائمة الموارد"]
    cli --> g["get: جلب الحالة الحالية"]
    cli --> t["test: حكم فقط بلا تغيير"]
    cli --> s["set: تطبيق (موارد تدعم Set)"]

الشكل 6: ابحث عن المورد بـ list، واقرأ القيمة الحالية بـ get، وتأكّد من الفرق عن التصريح بـ test، ثمّ انتقل إلى set.

يحتاج set الذي يغيّر الجهاز كلّه، مثل HKLM وإعدادات النظام، امتيازات المسؤول. ابدأ التجارب الأولى بأمثلة تحت المستخدم (مثل HKCU)، وتأكّد من الهدف والصلاحيات في أيّ عملية تتضمّن تغييراً. استخدام محوّل موارد PSDSC من سلالة Windows PowerShell يفترض أيضاً التشغيل بامتيازات المسؤول.⁷ فصل مستخدم التشغيل عن التكوين في الفصل 8.

5. مستند التكوين ── من التصريح إلى التحقّق بعد التطبيق

5.1. اجمع في YAML «ماذا ينبغي أن يكون وكيف»

مستند التكوين ملفّ YAML/JSON يصرّح بعدّة مثيلات موارد مجتمعة. كحدّ أدنى تعرّف $schema وresources، وتكتب لكلّ مثيل name (اسم عرض فريد داخل الوثيقة)، وtype (الاسم المؤهَّل بالكامل للمورد)، وproperties (الحالة المرغوبة).²

# standard-pc.dsc.config.yaml ── الحالة المرغوبة للجهاز القياسي
$schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
parameters:
  appMode:
    type: string
    defaultValue: standard
resources:
  - name: وضع تشغيل التطبيق
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: "[parameters('appMode')]"

في هذا المثال جُمع تصريح الفصل 3 في ملفّ، وصار وضع التشغيل معاملاً appMode. يمكن فصل القيم التي تختلف حسب القسم أو البيئة عن متن التكوين. تقلّل parameters وvariables التعريف المكرّر، وتعبّران أيضاً عن قيم ديناميكية. للتعبير تُستخدم مجموعة جزئية من دوال قوالب ARM.²

flowchart TB
    accTitle: بنية مستند التكوين
    accDescr: يتكوّن مستند التكوين من schema الذي يبيّن مخطّط الوثيقة، وparameters وvariables لامتصاص فروق البيئة، ومصفوفة resources لمثيلات الموارد، ولكلّ مثيل name وtype وproperties
    docroot["مستند التكوين (YAML / JSON)"] --> sch["$schema: معرّف URI لمخطّط الوثيقة"]
    docroot --> par["parameters / variables"]
    docroot --> res["resources: مصفوفة المثيلات"]
    res --> inst["name وtype وproperties"]
    par -.-> inst

الشكل 7: فصل مخطّط الوثيقة، وقيم كلّ بيئة، وتصريحات الموارد يجعل قصد الإعداد مقروءاً كبيانات.

ميزة صيرورة التكوين بيانات أنّك تراجع «ما الذي ينبغي ضبطه على هذا الجهاز» كفرق YAML. غير أنّ كونها بيانات لا يعني أنّها غير ضارّة. المورد المشار إليه يغيّر النظام، لذا يلزم أيضاً تأكيد الموثوقية في الفصل 8.⁸

5.2. تقدّم بالترتيب test ثمّ what-if ثمّ set ثمّ get

قبل التطبيق، أدخل المراقبة حتماً. يبلّغ dsc config test بوجود فرق عن الحالة المرغوبة أو غيابه، ويعرض dsc config set --what-if تنبؤاً دون تغيير.⁴

flowchart TB
    accTitle: أربع خطوات لتطبيق آمن
    accDescr: تتأكّد بـ dsc config test الذي لا يغيّر شيئاً من وجود فرق، وتعرض تنبؤ التغيير بخيار what-if لـ dsc config set، ثمّ تطبق بـ set بعد الاقتناع، وتتحقّق من النتيجة بـ get، بهذا الترتيب الآمن
    t["dsc config test (وجود الفرق)"] --> w["set --what-if (تنبؤ التغيير)"]
    w --> s["dsc config set (التطبيق)"]
    s --> g["dsc config get (التحقّق من النتيجة)"]

الشكل 8: انظر الفرق أوّلاً، وتأكّد من تنبؤ التغيير، ثمّ طبّق متى اقتنعت. أخيراً أعد قراءة الحالة الفعلية.

# 1. تأكيد وجود الفرق (بلا تغيير)
dsc config test --file .\standard-pc.dsc.config.yaml

# 2. عرض تنبؤ بما سيتغيّر إن طُبِّق (بلا تغيير)
dsc config set --file .\standard-pc.dsc.config.yaml --what-if

# 3. التطبيق بعد الاقتناع
dsc config set --file .\standard-pc.dsc.config.yaml

# 4. التحقّق من الحالة بعد التطبيق
dsc config get --file .\standard-pc.dsc.config.yaml

ما تراه هنا مختلف في كلّ خطوة. test حكم التطابق، وwhat-if تنبؤ التغيير، وget جلب الحالة الفعلية. إن لم ينفّذ المورد what-if مباشرة يُركَّب التنبؤ من نتيجة test، فلا تخلط التنبؤ بالقياس بعد التطبيق.⁴

بهذا الترتيب لا تصير تغييرات الإعداد رمية واحدة، بل حكماً في كلّ مرحلة. لا يُستعاض بتساوي المفعول أو what-if عن تأكيد صلاحيات التطبيق وموثوقية المورد.

5.3. إن بدأت من بيئة قائمة، صدّر الموارد الداعمة لـ export

dsc config export مدخل عكسي يكتب البيئة الحالية. إن سردت في وثيقة الدخل الممرَّرة بـ --file موارد تدعم export، أعاد إلى الإخراج القياسي مستند تكوين يتضمّن كلّ المثيلات القائمة لتلك الموارد.⁹

# تمرير وثيقة دخل تسرد الموارد المستهدفة، وحفظ مستند التكوين الحالي
dsc config export --file .\export-targets.dsc.config.yaml > .\current-state.dsc.config.yaml

ليس كلّ مورد قابلاً للكتابة، وتُعلَن كلّ نوع مورد في وثيقة الدخل مرّة واحدة فقط. اتّخذ الوضع الحاصل نقطة انطلاق، ثمّ قرّر ما تريد إدارته معياراً. export عملية تكتب الحالة الحالية؛ أمّا جعلها الحالة المرغوبة فقرار جهة التشغيل.⁹

flowchart TB
    accTitle: من الحالة الحالية إلى تصريح ما تريد إدارته
    accDescr: سرد موارد تدعم export في وثيقة الدخل يعطي مستند تكوين يتضمّن المثيلات القائمة، وبعد مراجعة محتواه تقرّر جهة التشغيل الحالة التي تُدار معياراً
    input["سرد موارد تدعم export"] --> export["dsc config export"]
    export --> current["وثيقة تكوين المثيلات القائمة"]
    current --> review["مراجعة المحتوى وتحديد المعيار"]
    review --> desired["تصريح الحالة المراد إدارتها"]

الشكل 9: كتابة الوضع الحالي، والحكم بما يُعتَمد معياراً، مرحلتان منفصلتان.

6. الاستفادة من الأصول القائمة ── المحوّل وWinGet Configuration

6.1. استدعِ موارد PSDSC بالمحوّل المناسب لبيئة التشغيل

حتّى إن كان v3 منتجاً آخر، لا تضيع موارد PSDSC القائمة. يمكن استدعاؤها من مستند تكوين v3 عبر مورد محوّل. تغيّرت الأسماء في DSC 3.2، فطابق إصدار التثبيت بأسماء المصادر.¹⁰

حتّى إن كان DSC نفسه مستقلّاً عن PowerShell، تعمل الموارد القائمة المستدعاة بالمحوّل في بيئة PowerShell المقابلة. جهة Windows PowerShell تستخدم PSDesiredStateConfiguration 1.1 المضمَّن، وتتعامل مع موارد السكربت والأصناف والثنائي المتوافقة.¹⁰

flowchart TB
    accTitle: بنية الطبقات حول DSC v3
    accDescr: تستدعي طبقة تنسيق مثل winget configure أو Azure Machine Configuration DSC v3، ويستدعي DSC v3 الموارد الأصلية مباشرة وموارد PSDSC القائمة عبر مورد محوّل، بهذه البنية الطبقية
    orch["winget configure وMachine Configuration"] --> dsc["dsc.exe (DSC v3)"]
    dsc --> native["موارد أصلية (مثل Registry)"]
    dsc --> adapter["مورد المحوّل"]
    adapter --> psdsc["موارد PSDSC القائمة (أصول PowerShell)"]

الشكل 10: يستدعي DSC v3 الموارد الأصلية مباشرة، ويستخدم أصول PowerShell القائمة عبر المحوّل.

6.2. في مخطّط v3 لـ WinGet حدّد DSC v3 معالجاً

جهة الاتصال الأخرى WinGet Configuration. ملفّات .winget التي عُرضت في مقالة تجهيز أجهزة PC تستخدم أيضاً، في مخطّط v3، DSC v3 معالجاً. المطلوب WinGet 1.11 فما بعده ومعالج dscv3.¹¹

حدّد dscv3 في metadata.winget.processor.identifier لملفّ التكوين، واكتب resources مباشرة في جذر الوثيقة. المحتوى مستند تكوين DSC v3.

# WinGet Configuration v3 ── المحتوى مستند تكوين DSC v3
$schema: https://raw.githubusercontent.com/PowerShell/DSC/main/schemas/2023/08/config/document.json
metadata:
  winget:
    processor:
      identifier: dscv3
resources:
  - name: وضع تشغيل التطبيق
    type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU\Software\MyCompany\App
      valueName: Mode
      valueData:
        String: standard

لا يمكن تمرير تنسيق v2 القائم إلى dscv3 كما هو. ملفّات v2 التي تحمل properties.configurationVersion: 0.2.0 وتضع الموارد تحت properties تواصل العمل على المعالج السابق. لوضعها على DSC v3، انقل الصيغة وفق «Convert to v3» في مستودع العيّنات الرسمي.¹¹

إذن فكّر فيما تعيد استخدامه مفصولاً. PSDSC حديث استدعاء الموارد بالمحوّل، وWinGet حديث مواءمة تنسيق ملفّ التكوين والمعالج. تصريح الحالة الذي تتعلّمه في DSC v3 أرضية مشتركة تصل من dsc.exe على جهازك إلى winget configure للتجهيز، ثمّ إلى طبقات إدارة أعلى مثل Machine Configuration.¹

7. التشغيل المستمر ── اجعل Git المصدر المعتمد واكشف الانحراف

7.1. أتمِت الكشف أوّلاً، وافصله عن الإصلاح

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

يُسمّى انحراف الإعداد يدوياً بعد التطبيق عن الحالة المصرَّح بها انحراف التكوين. كشفه تشغيل dsc config test دورياً. لا يغيّر test شيئاً، لذا يمكن فصل الكشف عن الإصلاح. أتمِت الكشف أوّلاً، ولا تُجرِ الإصلاح بـ set إلا بعد تأكيد الفرق.

flowchart TB
    accTitle: دورة تشغيل إدارة التكوين انطلاقاً من Git
    accDescr: تراجع مستند التكوين الموضوع في مستودع Git بطلب سحب ثمّ تطبقه، وتكشف الانحراف بـ test دوري عبر جدولة المهام أو CI، ثمّ تؤكّد الفرق وتعود إلى الإصلاح أو تحديث التكوين
    git["مستودع Git (مستند التكوين)"] --> pr["مراجعة التغيير بطلب سحب"]
    pr --> apply["التطبيق بـ dsc config set"]
    apply --> sched["تشغيل دوري: dsc config test"]
    sched -->|"كشف انحراف"| judge["تأكيد الفرق والحكم بالتعامل"]
    judge -.->|"التكوين صحيح"| fix["الإصلاح بـ set"]
    judge -.->|"الواقع صحيح"| git

الشكل 11: راجع التصريح ثمّ طبّقه، واكشف الفرق بـ test دوري. أمّا الإصلاح أو تحديث التصريح فيُقرَّر بعد رؤية المحتوى.

ليس الانحراف خطأ دائماً. إن كان نتيجة تغيير لزم في الموقع، لا تُعِد الجهاز بل حدّث مستند التكوين وراجعه وادمجه. وإن كان التصريح صحيحاً فأصلِح بـ set. في الحالين الانضباط نفسه: المصدر المعتمد داخل Git.

7.2. ميّز «تعذّر الفحص» عن «هناك انحراف»

في التشغيل الدوري، المهم ألّا تعدّ مجرّد تشغيل الأمر نجاحاً. المثال التالي يميّز فشل تنفيذ DSC، وخطأ فحص بعض الموارد، والانحراف، ويُنهي كلاً منها برمز غير صفري.

# للتشغيل الدوري: تمييز فشل test نفسه وخطأ المورد والانحراف، وإنهاء الكلّ بغير صفر
$json = dsc config test --file C:\config\standard-pc.dsc.config.yaml
if ($LASTEXITCODE -ne 0 -or -not $json) {
    Write-Error "فشل تنفيذ dsc config test نفسه (رمز الإنهاء: $LASTEXITCODE)"
    exit 2
}
$result = $json | ConvertFrom-Json
if ($result.hadErrors) {
    # فشل تحقّق الوثيقة أو إنهاء غير صفري لبعض الموارد. الفحص لم يكتمل فلا تبلّغ بالسلامة
    Write-Error "فشل فحص بعض الموارد. راجع messages"
    exit 2
}
if ($result.results.result.inDesiredState -contains $false) {
    Write-Error "كُشف انحراف تكوين"
    exit 1
}

flowchart TB
    accTitle: تمييز فشل الفحص الدوري عن الانحراف
    accDescr: في مثال الفحص الدوري تُراجع رمز إنهاء DSC والإخراج، ثمّ تُراجع أخطاء الفحص بـ hadErrors، وإن كان inDesiredState للنتيجة false يُبلَّغ بانحراف
    run["رمز إنهاء DSC والإخراج"] --> q1{"فشل التنفيذ أو لا إخراج؟"}
    q1 -->|"نعم"| error["فشل الفحص (إنهاء 2)"]
    q1 -->|"لا"| q2{"hadErrors؟"}
    q2 -->|"نعم"| error
    q2 -->|"لا"| q3{"inDesiredState يساوي false؟"}
    q3 -->|"نعم"| drift["كشف انحراف (إنهاء 1)"]
    q3 -->|"لا"| ok["لا فرق في هذا الفحص"]

الشكل 12: لا تبلّغ عن خطأ الفحص بأنّه «لا فرق». الانحراف نتيجة عدم تطابق الحالة بعد أن أمكن الفحص.

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

7.3. اختر بنية التشغيل الدوري وفق إدارة الجهاز والمنظّمة

ليس لـ DSC v3 LCM، لذا تقرّر على حدة متى ومن يشغّل test. للجهاز تصلح جدولة المهام، ولمجموعات الخوادم عدّاء CI. راجع مقالة تصميم التشغيل غير المراقب.

في المنظّمات التي تجمّع الإدارة نحو Azure، يصير Machine Configuration وعاءً يدير تدقيق إعدادات نظام التشغيل وتطبيقها على أجهزة Azure الافتراضية وخوادم الموقع عبر Azure Arc.¹² تختار تشغيل الأمر على الجهاز دورياً، أو وضعه على طبقة إدارة أعلى.

8. ما تؤكّده قبل التطبيق ── صلاحيات التشغيل والأسرار والموثوقية

8.1. افصل إعدادات المستخدم عن إعدادات الجهاز في مرحلة التكوين

يحتاج set الذي يمسّ الجهاز كلّه، مثل HKLM وميزات Windows، ترقية صلاحيات. واستخدام موارد PSDSC من سلالة Windows PowerShell عبر المحوّل يفترض أيضاً التشغيل بامتيازات المسؤول.⁷

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

flowchart TB
    accTitle: فصل سياق التنفيذ وفق هدف التكوين
    accDescr: تُفصل إعدادات المستخدم عن إعدادات الجهاز في مستند التكوين، ويُمرَّر التشغيل التفاعلي أو الدوري بعد تأكيد المستخدم المستهدف والصلاحيات اللازمة
    config["الإعدادات المراد إدارتها"] --> user["تكوين على مستوى المستخدم"]
    config --> machine["تكوين على مستوى الجهاز"]
    user --> check["تأكيد المستخدم المستهدف والصلاحيات"]
    machine --> check
    check --> exec["تشغيل تفاعلي أو دوري"]

الشكل 13: لا تكتفِ بتوزيع YAML بالطريقة نفسها؛ قرّر أيضاً بأيّ مستخدم وصلاحيات يُطبَّق هذا التكوين.

8.2. لا تُدخل الأسرار إلى Git، وأكّد حتّى الموارد المشار إليها

مستند التكوين بيانات تُوضَع في Git. لا تكتب كلمات المرور ومفاتيح API مباشرة؛ صمّم جعلها معاملات وتمريرها عند التشغيل. معاملات الفصل 5 مثال لفصل فروق البيئة، وفصل الأسرار عن متن التكوين مهمّ كذلك.

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

9. خلاصة ── من إعدادات صغيرة، اصنع مصدراً معتمداً قابلاً للتنفيذ

إن كنت تبدأ IaC تصريحيّاً لـ Windows الآن، فالخيار Microsoft DSC v3 (dsc.exe). بعد تمييز سلالات DSC الأربع، راقب أوّلاً بـ get وtest المنفردين، ثمّ اجمع في تكوين YAML/JSON. عند التطبيق افصل الحكم والتنبؤ والتطبيق والتأكيد بالترتيب test ثمّ what-if ثمّ set ثمّ get.⁵⁴

إمكان التطبيق مراراً لأنّك تكتب «الحالة المرغوبة» لا «الإجراءات»، ويتولّى DSC والموارد المقارنة والتطبيق اللازم. موارد PSDSC القائمة يمكن إعادة استخدامها عبر المحوّل، وأصول WinGet تتّصل بعد ترحيل الصيغة إلى مخطّط v3.³¹⁰¹¹

في التشغيل المستمر افترض أن v3 نفسه بلا LCM. ضع المصدر المعتمد للتكوين في Git، واكشف الانحراف بـ test دوري، فإن صحّ التكوين فأصلِح، وإن صحّ الواقع فحدّث التكوين.¹ صمّم أيضاً صلاحيات التشغيل والأسرار وموثوقية المشار إليه مع إجراءات التطبيق.

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

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

• أتمتة تجهيز أجهزة PC بـ winget وPowerShell ── اجعل الإجراءات قابلة للتنفيذ
• هل ينبغي ترحيل BAT إلى PowerShell ── معايير القرار وممارسة الترحيل
• مهام جدولة المهام لا تُنفَّذ أو تنتهي بـ 0x1 ── عزل السبب وتصميم تشغيل آمن
• دليل الترحيل من GPO إلى Intune ── حلّ واقعي للمنشآت الصغيرة والمتوسّطة
• إدارة Windows Update بعد إهمال WSUS

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

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

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

روابط مرجعيّة

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

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

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

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

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

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

يبدو أن لـ DSC عدّة إصدارات. أيّها أستخدم؟

إن كنت تبدأ إدارة تكوين تصريحية الآن فاستخدم Microsoft DSC v3 (dsc.exe). لـ DSC أربع سلالات: PSDSC v1.1 المضمَّن في Windows PowerShell 5.1، وPSDSC v2 كوحدة لـ PowerShell 7، وPSDSC v3 (معاينة) المستخدم لدعم Linux في Azure Machine Configuration، وMicrosoft DSC v3 المعاد كتابته أمراً مستقلّاً لا يعتمد على PowerShell. v3 متعدّد المنصّات، ويكتب التكوين بيانات YAML/JSON لا سكربتات PowerShell، ويمكنه إعادة استخدام موارد PSDSC القائمة عبر محوّلات. عند البحث، إضافة «DSC v3» أو «dsc.exe» تسهّل فصل النتائج عن مواد الأجيال الأقدم.

ما الفرق بين DSC v3 وسكربت إجراءات (BAT أو PowerShell)؟

يصف سكربت الإجراءات «الخطوات المراد تنفيذها»، لذا عليك بناء تساوي المفعول بنفسك لتتجنّب التطبيق المزدوج أو الأخطاء في التشغيل الثاني. يكتب DSC «الحالة المرغوبة» بيانات، وتتولّى الموارد المقارنة بالحالة الحالية (test) وتطبيق الفرق (set). مهما كرّرت تشغيل مستند التكوين نفسه لا يفعل شيئاً للبنود التي هي أصلاً في الحالة المرغوبة، لذا يمكنك التوزيع وإعادة التشغيل دون القلق من عدد التشغيلات. ولأن التكوين بيانات YAML، تكون مراجعات الفرق وتاريخ الإصدارات في Git أسهل بكثير ممّا مع السكربتات.

هل ستضيع موارد PowerShell DSC القائمة وأصول WinGet Configuration؟

لا. يستطيع DSC v3 استدعاء موارد PSDSC القائمة القائمة على الأصناف وعلى MOF عبر موارد محوّل (Microsoft.Adapter/PowerShell وMicrosoft.Adapter/WindowsPowerShell في DSC 3.2 فما بعده؛ وMicrosoft.DSC/PowerShell وMicrosoft.Windows/WindowsPowerShell قبل ذلك). ويستخدم WinGet Configuration، من مخطّط v3 (WinGet 1.11 فما بعده)، DSC v3 معالجاً له. تواصل ملفّات .winget بتنسيق v2 العمل على المعالج السابق، لكن لوضعها على معالج DSC v3 تحتاج تحويلها إلى تنسيق v3 باتّباع دليل التحويل الرسمي.

كيف أُنفذ تكويناً «باستمرار» بـ DSC v3؟

DSC v3 نفسه أداة تُشغَّل أمراً؛ ليس له وكيل مقيم ولا آلية إصلاح تلقائي مثل LCM (Local Configuration Manager) في v1.1. إن احتجت تطبيقاً وتدقيقاً مستمرّين، فإمّا ابنِ كشف انحرافك بتشغيل dsc config test دورياً من Task Scheduler أو CI، أو ضعه على طبقة تنسيق مثل Azure Machine Configuration (التي يمكنها أيضاً تغطية خوادم في الموقع عبر Azure Arc).

أتردّد في تشغيل dsc config set مباشرة. هل يمكنني فحص الأثر مسبقاً؟

نعم. تشغيل dsc config test يُظهر أيّ مثيلات موارد ليست في الحالة المرغوبة، بلا إجراء تغييرات. إضافة إلى ذلك يملك dsc config set خيار --what-if الذي يعرض تنبؤاً بـ «ماذا سيتغيّر، وكيف، لو شُغِّل هذا» دون تغيير شيء فعلاً. افحص الفروق بـ test و--what-if أوّلاً، وشغّل set فقط متى اقتنعت؛ ذلك التسلسل آمن.

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

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

غو كومورا

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

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