فشل تثبيت RRAS بسبب تعليق خدمة RemoteAccess

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

ابدأ بالخدمة لا بمعالج الدور

افتح موجه أوامر مرفوعًا واقرأ إعدادات الخدمة قبل أن تمسّ الدور. هناك قيمتان تهمّان: نوع البدء والحساب الذي تعمل تحته الخدمة. التثبيت الافتراضي يسجّل الخدمة لبدء تلقائي مؤجّل تحت Network Service.

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

معالج الدور لا يبلّغ إلا بأن التهيئة فشلت، ولهذا بالضبط تأتي تشخيص الخدمة أولًا.

اقرأ حق تسجيل الدخول قبل إعادة التثبيت

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

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

secedit /export /cfg C:\Windows\Temp\secpol-export.inf
Select-String -Path C:\Windows\Temp\secpol-export.inf -Pattern SeServiceLogonRight
sc.exe qc RemoteAccess
Get-Service RemoteAccess | Format-List Name, Status, StartType

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

رحلة الحساب ذهابًا وإيابًا التي تعيد كتابة الإعدادات

هناك طريق مختصر يصلح إعدادات تسجيل دخول الخدمة دون تحرير السياسة يدويًا: غيّر الحساب، ثم طبّق، ثم أعد التغيير مع ترك حقلي كلمة المرور فارغين.

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

sc.exe config RemoteAccess obj= "NT AUTHORITY\LocalService" start= demand
Start-Service RemoteAccess
sc.exe config RemoteAccess obj= "NT AUTHORITY\NetworkService" start= delayed-auto
Start-Service RemoteAccess

اقرأ الحالة بعد كل أمر، لأن خدمة تبدأ تحت حساب ولا تبدأ تحت الآخر تدلّك على الحق الناقص.

ثبّت الدور وأثبت أنه مثبّت

بعد أن تعمل الخدمة، أضف الدور من جديد وضمّن الميزة الفرعية للـ VPN التي تنوي استخدامها فعلًا. الدور العام وحده لا يمنحك نقطة نهاية VPN عاملة.

Install-WindowsFeature DirectAccess-VPN -IncludeManagementTools
Get-WindowsFeature RemoteAccess, DirectAccess-VPN, Routing
Get-Service RemoteAccess

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

دوّن ما غيّرته

أول خيارات المعالج تحدد قواعد الجدار الناري وتعيين العناوين وما إذا كان الخادم يتوقع مرحّل DHCP. وحفنة من عملاء النقطة إلى الموقع لا تحتاج إلى شكل نقطة نهاية موقع إلى موقع. قرّر الدور ومجموعة العناوين وطريقة المصادقة ومصدر الشهادة قبل النقر للمتابعة. والتخمين هنا ينتج خادمًا يُثبَّت بنظافة ولا يقبل اتصالًا أبدًا.

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