RRAS का इंस्टॉलेशन विफल होता है क्योंकि RemoteAccess सेवा अटक जाती है
Routing and Remote Access भूमिका विफल हो सकती है क्योंकि उसकी सेवा Starting पर अटकी रहती है। कुछ भी दोबारा इंस्टॉल करने से पहले सेवा के रूप में लॉग-ऑन का अधिकार जाँचें।
भूमिका का इंस्टॉलेशन एक सामान्य त्रुटि के साथ रुक जाता है और इवेंट लॉग में काम करने के लिए लगभग कुछ भी नहीं होता। जिन सर्वरों पर ऐसा होता है, वहाँ गायब हिस्सा विज़ार्ड में ही नहीं है: Remote Access सेवा कभी Starting स्थिति नहीं छोड़ती। जो भूमिका अपना आरंभ पूरा नहीं कर पाती, वह हर पुनः प्रयास में फिर विफल होती है, इसलिए पहले सेवा आती है और बाद में विज़ार्ड। लॉग-ऑन अधिकार ठीक करने में मिनट लगते हैं, और भूमिका को बार-बार दोबारा इंस्टॉल करने में नहीं।
भूमिका विज़ार्ड से नहीं, सेवा से शुरू करें
एक उन्नत प्रॉम्प्ट खोलें और भूमिका को छूने से पहले सेवा का कॉन्फ़िगरेशन पढ़ें। दो मान मायने रखते हैं: स्टार्ट प्रकार और वह खाता जिसके अंतर्गत सेवा चलती है। डिफ़ॉल्ट इंस्टॉलेशन सेवा को Network Service के अंतर्गत स्वचालित, विलंबित स्टार्ट के लिए पंजीकृत करता है।
यदि स्थिति Running के बजाय Starting पर टिकी है, तो सेवा किसी ऐसी चीज़ की प्रतीक्षा कर रही है जो उसे मिल नहीं सकती, और लॉग-ऑन अधिकार ही सामान्य उम्मीदवार है। ज़्यादा देर प्रतीक्षा करने से लाभ नहीं होता, क्योंकि स्टार्ट पहले ही ऐसे विफल हो चुका है जिसे Service Control Manager लंबित बताता है। सेवा को साफ़ तरीके से रोकें और उसका कॉन्फ़िगरेशन फिर पढ़ें। फिर इवेंट लॉग में सेवा के स्टार्ट प्रयास को देखें, क्योंकि वहीं विफलता के साथ खाते का नाम दिखता है।
भूमिका विज़ार्ड केवल यह बताता है कि आरंभ विफल रहा, और इसीलिए सेवा का निदान पहले आना चाहिए।
दोबारा इंस्टॉल करने से पहले लॉग-ऑन अधिकार पढ़ें
शुरू होने के लिए 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
पुष्टि करें कि उप-सुविधाएँ Available के बजाय Installed बताती हैं, फिर कंसोल खोलें और किसी और के मशीन छूने से पहले प्रारंभिक कॉन्फ़िगरेशन पूरा करें। यदि कंसोल अब भी कहता है कि सेवा नहीं चल रही, तो भूमिका हटाने के बजाय सेवा जाँच पर लौटें।
लिखें कि आपने क्या बदला
विज़ार्ड की पहली पसंद फ़ायरवॉल नियम, पता आवंटन और यह तय करती है कि सर्वर DHCP रिले की अपेक्षा करता है या नहीं। मुट्ठी भर पॉइंट-टू-साइट क्लाइंट को साइट-टू-साइट एंडपॉइंट का आकार नहीं चाहिए। क्लिक करने से पहले भूमिका, पता पूल, प्रमाणीकरण विधि और प्रमाणपत्र का स्रोत तय करें। यहाँ अनुमान लगाने से ऐसा सर्वर बनता है जो साफ़ इंस्टॉल होता है और कभी कनेक्शन स्वीकार नहीं करता।
सेवा-खाते का विचलन उसी नोट में रखें। डिफ़ॉल्ट खाता वापस लाने वाला कोई कठोरीकरण दौर अगले रीस्टार्ट पर गड़बड़ी लौटा सकता है, उसके महीनों बाद जिसने इसका निदान किया था वह आगे बढ़ चुका हो।