SYSTEM कार्य VPN प्रोफ़ाइल के लिए कौन सी फ़ोन बुक खोजता है?

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

दो स्टोर एक ही प्रोफ़ाइल नाम रखते हैं

मूल Windows VPN प्रोफ़ाइल उस खाते के स्टोर में रहती है जिसने उसे बनाया। वैश्विक स्टोर एक अलग फ़ोन बुक है, जो केवल तब भरता है जब प्रोफ़ाइल उन्नत सत्र में सभी उपयोगकर्ताओं वाले स्विच के साथ बनाई जाती है। दोनों एक ही नाम की प्रोफ़ाइल रख सकते हैं, और इनमें से कोई भी दूसरे का दृश्य नहीं है।

दोनों स्टोर एक ही सत्र से पढ़ें और उनके लौटाए नामों की तुलना करें। स्विच वैश्विक स्टोर चुनता है, और उसे पढ़ने के लिए आम तौर पर उन्नत सत्र चाहिए:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType

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

क्रेडेंशियल से पहले कार्य का principal पढ़ें

कार्य खोलें और principal पढ़ें, क्योंकि यह बताता है कि कार्य कौन सा स्टोर देख सकता है। SYSTEM के रूप में चलने के लिए सेट किया गया कार्य आपका अतिरिक्त अधिकारों वाला खाता नहीं है: इसकी अपनी प्रोफ़ाइल है और साइन इन रहते हुए आपके द्वारा बनाई गई प्रति-उपयोगकर्ता फ़ोन बुक तक इसकी कोई पहुँच नहीं है। सेवा खाता ठीक उसी तरह व्यवहार करता है।

आप साइन इन हैं या नहीं, इसकी परवाह किए बिना चलाने का विकल्प भी इसे बदलता है, क्योंकि तब कार्य के पास कोई इंटरैक्टिव सत्र नहीं होता जिसके क्रेडेंशियल उधार लिए जा सकें। क्रिया को whoami किसी फ़ाइल में लिखने दें और मानने के बजाय उत्तर पढ़ें।

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

प्रोफ़ाइल ढूँढना साइन इन करना नहीं है

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

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

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

कार्य रिकॉर्ड को आवश्यक चार फ़ील्ड

परिणाम तय करने वाले मानों को एक ही स्थान पर साथ रखें, क्योंकि उनमें से तीन आम तौर पर निहित रह जाते हैं। रिकॉर्ड को चार पंक्तियाँ चाहिए:

• क्रिया पथ: वह स्क्रिप्ट या निष्पादन योग्य फ़ाइल जो कार्य चलाता है, न कि ऐसा शॉर्टकट जो दूसरे खाते के लिए अलग तरह से हल होता है।
• प्रोफ़ाइल नाम: सटीक स्ट्रिंग, क्योंकि दो स्टोर अलग-अलग सर्वरों की ओर इशारा करते हुए एक ही नाम रख सकते हैं।
• Principal: वह खाता जिसके अंतर्गत कार्य चलता है, और क्या उसका इंटरैक्टिव सत्र है।
• प्रमाणीकरण विधि: वह principal वास्तव में क्या पूरा कर सकता है, जैसे आपकी उपयोगकर्ता प्रोफ़ाइल में कुंजी के बजाय मशीन-स्टोर प्रमाणपत्र।

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

कार्य जिस चरण तक पहुँचा उसे पहचानें

अंतिम रन के परिणाम से अनुमान लगाने के बजाय क्रिया को उपकरणयुक्त करें। एक छोटा रैपर पहचान, वह स्टोर जो वह देख सकता है और डायल परिणाम एक ही स्थान पर दर्ज करता है:

whoami
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress
rasdial "Office"
schtasks /query /tn "VPN Connect" /v /fo LIST

डायल कमांड अपनी त्रुटि छापता है, जो आम तौर पर सामान्य कार्य विफलता से अधिक स्पष्ट होती है। क्वेरी principal और अंतिम परिणाम कोड साथ-साथ लौटाती है, इसलिए पहचान और परिणाम एक ही दृश्य में दिखते हैं। वे दो तथ्य तय करते हैं कि अगला कदम स्टोर परिवर्तन है या क्रेडेंशियल परिवर्तन।

अंत में, उपयोगकर्ता के साइन इन होने के बाद जुड़ने वाले कार्य को डिवाइस टनल या समर्थित प्री-लॉगिन वर्कफ़्लो से अलग करें। एक प्रोफ़ाइल साझा करना दोनों में से किसी के लिए डिज़ाइन नहीं है, और principal फ़ील्ड ही बताता है कि आपने तीन में से कौन सा बनाया है। यदि कनेक्टिविटी लॉगिन से पहले होनी ही है, तो प्रति-उपयोगकर्ता प्रोफ़ाइल स्टोर ठीक करने के लिए गलत परत है।