VPN से कनेक्ट होने पर आपकी लॉगऑन स्क्रिप्ट दोबारा नहीं चलती

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

चार निर्णय इस हैरानी को ठीक से व्यवहार करने वाले कार्यप्रवाह में बदलते हैं, और पहला यह जानना है कि स्क्रिप्ट किन घटनाओं पर चलती है।

स्क्रिप्टें जीवनचक्र की उन घटनाओं पर चलती हैं जिन्हें आप दोबारा नहीं चला सकते

कंप्यूटर पक्ष की नीति मशीन के बूट होने पर और उपयोगकर्ता पक्ष की नीति किसी के साइन इन करने पर लागू होती है, जबकि पृष्ठभूमि रीफ़्रेश बिना कुछ पुनः आरंभ किए वही सेटिंग्स दोहराता है। वह रीफ़्रेश स्क्रिप्ट एक्सटेंशन को संसाधित करता है, पर अलग-अलग स्क्रिप्टें दोबारा नहीं चलाता, जो केवल स्टार्टअप, शटडाउन, लॉगऑन या लॉगऑफ़ पर चलती हैं। इसलिए gpupdate /force सफलता बता सकता है जबकि मैपिंग अभी भी अनुपस्थित है, और साफ़ रीफ़्रेश इस बात का प्रमाण नहीं है कि स्क्रिप्ट ने कुछ किया।

नीति प्रसंस्करण पर Microsoft का संदर्भ ठीक वही रेखा खींचता है—एक्सटेंशन को संसाधित करने और उसमें जो है उसे चलाने के बीच—और जब कोई कहता है कि रीफ़्रेश को स्क्रिप्ट दोबारा चलानी चाहिए थी, तब यही पृष्ठ उद्धृत करने योग्य है।

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

काम को कनेक्शन से बाँधें, लॉगऑन से नहीं

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

कनेक्शन के बाद होने वाले काम के लिए कनेक्शन-ट्रिगर कार्य या वह कनेक्शन क्रिया उपयोग करें जिसे क्लाइंट समर्थित करता है। जाँचें कि क्लाइंट वास्तव में कौन-सी घटना उत्सर्जित करता है, क्योंकि Windows के मूल VPN क्लाइंट की उठाई घटना तीसरे पक्ष का क्लाइंट नहीं उठाता। साइन इन से पहले होने वाले मशीन कॉन्फ़िगरेशन के लिए समर्थित उत्तर डिवाइस टनल या लॉगऑन-पूर्व कोई अन्य डिज़ाइन है, न कि डेस्कटॉप दिखने पर चलने वाला कार्य। काम उसी पहचान और सत्र में चलाएँ जिन्हें इसकी ज़रूरत है, क्योंकि SYSTEM के रूप में बनी मैपिंग ऐसे सत्र में पहुँचती है जिसे उपयोगकर्ता कभी नहीं देखता।

काम करने से पहले तैयारी जाँचें, और ज़ोर से विफल हों

कनेक्शन घटना DNS या फ़ाइल सर्वर के उपयोगी होने से पहले आ सकती है, इसलिए कार्य को मानने के बजाय जो चाहिए उसकी जाँच करनी चाहिए। विशिष्ट नाम हल करें, विशिष्ट कनेक्शन आज़माएँ, और सीमा और विलंब के साथ पुनः प्रयास करें: छोटे लूप में Resolve-DnsName files.corp.example अभी-नहीं को कभी-नहीं से अलग करता है। अंतिम प्रयास के बाद नाम और त्रुटि के साथ ठोस विफलता की सूचना दें।

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

चार चीज़ें सत्यापित करें, फिर इसे दोहराने योग्य बनाएँ

पायलट के दौरान एक के बजाय चार अवलोकन दर्ज करें: कनेक्शन घटना चली, कार्य शुरू हुआ, संसाधन ने जवाब दिया, और अनुरोधित परिवर्तन वास्तव में हुआ। यदि लॉग कार्य शुरू हुआ पर रुकता है, तो असली विफलता कितनी भी देर प्रतीक्षा करें, अदृश्य रहती है। फिर gpresult /scope user /v चलाएँ ताकि दिखे कि सत्र अपनी नीति क्या मानता है, और उसकी तुलना अपेक्षित सेटिंग से करें। GPO को लागू बताने वाली रिपोर्ट मैपिंग के बारे में अब भी कुछ नहीं कहती।

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

जहाँ स्वचालित ट्रिगर उपयुक्त नहीं है, वहाँ वही हस्ताक्षरित स्क्रिप्ट चलाने वाली स्वीकृत उपयोगकर्ता क्रिया वैध डिज़ाइन है। यह लॉगऑन घटना हुई होने का दिखावा करने के बजाय समय को स्पष्ट करती है।