RasMan और RemoteAccess एक ही सेवा नहीं हैं

RasMan और RemoteAccess सेवा सूची में एक-दूसरे के बगल में दिखते हैं, दोनों दूरस्थ पहुँच का ज़िक्र करते हैं, और वे अलग-अलग काम करते हैं। एक क्लाइंट कनेक्शन प्रबंधित करता है, और दूसरा रूटिंग और दूरस्थ पहुँच की सर्वर भूमिका है। उन्हें एक-दूसरे के विकल्प मानना ही वह तरीका है जिससे लैपटॉप में क्लाइंट की समस्या ठीक करने के लिए सर्वर सुविधा सक्षम हो जाती है। कोई सेवा नाम से प्रासंगिक और काम से अप्रासंगिक हो सकती है, जिससे टिकट में नाम सबसे कम उपयोगी सबूत बन जाते हैं।

दो नाम, दो अलग काम

RasMan वह कनेक्शन प्रबंधक है जो क्लाइंट पक्ष की दूरस्थ पहुँच संभालता है, जिसमें फ़ोनबुक और वह कनेक्शन तंत्र शामिल है जिसका उपयोग अंतर्निहित VPN क्लाइंट करता है। RemoteAccess रूटिंग और दूरस्थ पहुँच सेवा है, जो राउटर के रूप में काम करने वाली मशीन पर रूटिंग, NAT और सर्वर पक्ष की दूरस्थ पहुँच प्रदान करती है। Microsoft का RAS अवलोकन उस क्लाइंट मॉडल का वर्णन करता है, और VPN डायल करने वाले वर्कस्टेशन को दोनों में से केवल पहले की ज़रूरत होती है। दूसरे को इंस्टॉल या शुरू करने से पहला बेहतर नहीं हो जाता।

केवल पढ़ने वाली सूची में कुछ भी खर्च नहीं होता और वह पहले सवाल का जवाब सेकंडों में दे देती है। दोनों पठन चलाएँ और आउटपुट क्लाइंट की त्रुटि के पास रखें, क्योंकि अनुपस्थित सेवा और रुकी हुई सेवा अलग-अलग शुरुआती बिंदु हैं।

Get-Service -Name RasMan,RemoteAccess -ErrorAction SilentlyContinue | Select-Object Name,Status,StartType
Get-VpnConnection | Select-Object Name,ConnectionStatus,ServerAddress

मैन्युअल स्टार्ट प्रकार वाली रुकी हुई RasMan वह सेवा है जिसे नीति ने बंद किया, और यह प्रबंधन का सवाल है, गायब सुविधा नहीं। RemoteAccess का अनुपस्थित होना वर्कस्टेशन की सामान्य स्थिति है और क्लाइंट के बारे में कुछ नहीं कहता। कनेक्शन सूची महत्वपूर्ण है क्योंकि वह दिखाती है कि किसी सेवा को विफलता का दोषी ठहराने से पहले Windows प्रोफ़ाइल के होने को मानता है या नहीं।

क्लाइंट वास्तव में किस पर निर्भर है

विफल क्लाइंट की असली निर्भरता और उसकी पहली त्रुटि पहचानें, आखिरी नहीं। नीति से रुकी सेवा कई संभावनाओं में से एक है। डिफ़ॉल्ट रूट के लिए लड़ते दो क्लाइंट, गलत अडैप्टर पर लागू निजी DNS, पुराने उत्पाद द्वारा छोड़ा गया फ़िल्टर ड्राइवर, और ऐसी सुरक्षा नीतियाँ जिन्हें कभी साथ रहना नहीं था, हर एक अपनी त्रुटि पैदा करता है। इनमें से कोई भी स्टार्टअप मोड से ठीक नहीं होता। यह सूची ही कारण है कि स्टार्टअप मोड खराब पहला कदम है, क्योंकि एक डायलॉग पाँच अलग कारण छिपा सकता है।

पहली त्रुटि आखिरी से ज़्यादा मायने रखती है, क्योंकि उसके बाद सब कुछ परिणाम है। बदलाव करने से पहले उसे दर्ज करें, वरना सबूत लक्षण के साथ गायब हो जाएगा।

यहाँ RRAS सक्षम करने से कुछ क्यों नहीं सुधरता

रूटिंग भूमिका चालू करने से एक सेवा, रजिस्ट्री कॉन्फ़िगरेशन का एक सेट और कुछ संस्करणों में प्रारंभिक कॉन्फ़िगरेशन के बारे में संकेत जुड़ते हैं। इनमें से कुछ भी क्लाइंट निर्भरता नहीं देता, और प्रबंधित लैपटॉप पर यह बेसलाइन का उल्लंघन कर सकता है। किसी एक मशीन को संयोग से ठीक करने वाली सेवा के बारे में एक व्यक्ति की फ़ोरम पोस्ट पूरे फ़्लीट में रूटिंग सुविधाएँ सक्षम करने की नीति नहीं है। सेवा परिवर्तन के लिए ज़रूरी है कि भूमिका और परिनियोजन दस्तावेज़ किसी के उसे छूने से पहले सहमत हों।

उस कॉन्फ़िगरेशन को सिस्टम का मालिक रखता है, वह नहीं जिसने संयोग से थ्रेड पढ़ा। फ़्लीट भर में बेसलाइन बहाव को वापस लौटाना महंगा है, और हर सक्षम भूमिका एक और चीज़ है जिसे अगले ऑडिट को उचित ठहराना होगा। अगर भूमिका वास्तव में मशीन की है, तो वह निर्णय इस टिकट से महीनों पहले का है।

काम करने वाली मशीन से तुलना करें

एक काम करने वाली मशीन से तुलना करें जो वही क्लाइंट संस्करण और वही इच्छित प्रोफ़ाइल चलाती है, न कि उससे जिसमें डेस्कटॉप शॉर्टकट के वही नाम हैं। दो जुड़े संकेतक एक सुसंगत नेटवर्क नीति का मतलब नहीं हैं, और समर्थित सहअस्तित्व की जाँच तुलना का हिस्सा है। दोनों मशीनों पर क्लाइंट संस्करण, त्रुटि, मौजूद सेवाएँ और लागू रूट दर्ज करें। फिर तय करें कि अंतर सेवा है, रूट है, नीति है या संस्करण।

मिलते-जुलते नाम इस बात का संकेत हैं कि कहाँ देखना है, और उनका पूरा मूल्य इतना ही है। निदान के लिए पहली त्रुटि, तुलना की मशीन और बदलाव से पहले का रिकॉर्ड चाहिए।