VPN कनेक्ट होने पर कार्य चलाएँ: इवेंट, पोलिंग या क्रेडेंशियल?
लॉगऑन स्क्रिप्ट सुरंग बनने से पहले चलती है। नेटवर्क इवेंट ट्रिगर, संसाधन पोलिंग और संग्रहीत क्रेडेंशियल की तुलना करें कि हर एक क्या गारंटी देता है।
जो लॉगऑन स्क्रिप्ट ड्राइव मैप करती है या सिंक कार्य शुरू करती है, वह सुरंग को पता मिलने से पहले चलती है, इसलिए वह चुपचाप विफल हो जाती है और उपयोगकर्ता हर सुबह उसे हाथ से ठीक करता है। Windows अधिकांश क्लाइंट के लिए प्रति-VPN कनेक्ट कॉलबैक नहीं देता, लेकिन नेटवर्क परिवर्तन लॉग करता है, और वह रिकॉर्ड सही पल में काम शुरू कर सकता है। चुनाव उस रिकॉर्ड पर प्रतिक्रिया, संसाधन की पोलिंग और उस प्रॉम्प्ट को हटाने के बीच है जिसने विफलता को दृश्य बनाया।
तीनों तंत्रों की तुलना उनकी गारंटी के आधार पर करना उन्हें लालित्य के आधार पर क्रमबद्ध करने से बेहतर है। हर एक अलग तरह से विफल होता है, और विफलता का तरीका वही है जिसके साथ आप बाद में जीते हैं।
लॉगऑन बहुत जल्दी क्यों चलता है
लॉगऑन और स्टार्टअप VPN एडाप्टर को उसका पता मिलने से पहले चलते हैं, इसलिए उस पल में आज़माई गई ड्राइव मैपिंग, आंतरिक URL या डेटाबेस कनेक्शन के पास न रूट होता है न रिज़ॉल्वर। अनुरोध विफल हो जाता है, और सत्र ऐसी स्थिति में रह जाता है जिसे उपयोगकर्ता को हाथ से ठीक करना पड़ता है। उसी स्क्रिप्ट को स्टार्टअप फ़ोल्डर में ले जाने से कुछ नहीं बदलता, क्योंकि क्रम की समस्या उसके साथ चलती है। ट्रिगर सत्र घटना नहीं, नेटवर्क परिवर्तन होना चाहिए।
लॉगऑन पर मनमाने विलंब के साथ निर्धारित कार्य समाधान जैसा दिखता है और वास्तव में अनुमान है। यह तेज़ लिंक पर काम करता है और धीमे पर विफल होता है, जो विश्वसनीयता का सबसे बेकार प्रकार है।
तीन हुक की तुलना
तंत्र इस बात में भिन्न हैं कि वे क्या देखते हैं, कितनी जल्दी प्रतिक्रिया देते हैं और दिन में बाद में फिर से कनेक्ट होने पर क्या करते हैं। तालिका उनकी तुलना इन तीन बिंदुओं पर करती है, हर एक कितना चतुर लगता है उस पर नहीं।
| Mechanism | Reacts to | Covers a mid-session reconnect | Typical failure |
|---|---|---|---|
| Network profile event | A network connect record | Yes, when the event repeats | Runs on the wrong network |
| Resource poll with backoff | The resource becoming reachable | Yes | Log noise and a wasted window |
| Stored credentials alone | Nothing; it removes a prompt | No | Still fires before the tunnel |
तालिका को पंक्ति दर पंक्ति पढ़ें। इवेंट हुक सबसे तेज़ और सबसे शोरगुल वाला है, क्योंकि Windows कैफ़े के Wi-Fi सहित हर नेटवर्क दर्ज करता है, इसलिए क्रिया को कुछ भी करने से पहले संसाधन सत्यापित करना चाहिए। पोलिंग धीमी और अधिक सटीक है, क्योंकि वह ठीक तब सफल होती है जब शेयर या होस्टनाम उत्तर देता है, और उसे यह जानने की ज़रूरत नहीं होती कि कौन सा क्लाइंट स्थापित है। संग्रहीत क्रेडेंशियल बिलकुल प्रतिस्पर्धी विकल्प नहीं हैं: वे पासवर्ड प्रॉम्प्ट हटाते हैं, जो लॉगऑन के समय मैपिंग विफल होने का दूसरा और स्वतंत्र कारण है।
पहले दो में से चुनाव इस पर निर्भर है कि क्लाइंट पर कोई उपयोगी इवेंट मौजूद है या नहीं। जहाँ है, वहाँ इवेंट के साथ संसाधन जाँच बेहतर डिफ़ॉल्ट है।
इवेंट ट्रिगर सही ढंग से बनाएँ
रिकॉर्ड Microsoft-Windows-NetworkProfile/Operational लॉग में रहता है, और ID 10001 उस नेटवर्क को चिह्नित करता है जो अभी कनेक्ट हुआ। उस लॉग, उस प्रदाता नाम और उस पहचानकर्ता पर लक्षित इवेंट पर ट्रिगर के साथ कार्य बनाएँ। मशीन जिस भी नेटवर्क से जुड़ेगी वह उसे चलाएगा, इसलिए क्रिया को अनुमान नहीं, गार्ड क्लॉज़ चाहिए, और यदि काम मैप किए गए ड्राइव को छूता है तो उसे केवल तभी चलना चाहिए जब उपयोगकर्ता लॉगऑन हो।
गार्ड क्लॉज़ को वह जाँचना चाहिए जो कार्य को वास्तव में चाहिए, जैसे शेयर पथ या सेवा पोर्ट, और जब वह पहुँच से बाहर हो तो चुपचाप बाहर निकलना चाहिए। एडाप्टर का नाम जाँचना पर्याप्त नहीं है, क्योंकि क्लाइंट एक एडाप्टर को कई प्रोफ़ाइल में दोबारा इस्तेमाल कर सकता है। चुपचाप बाहर निकलना लॉग को पठनीय रखता है और ऐसे नेटवर्क के खिलाफ पुनः प्रयास का तूफ़ान रोकता है जो कभी संसाधन नहीं देगा।
जाँचें कि कार्य सही पल में चलता है
कॉन्फ़िगरेशन नहीं, समय साबित करें। नीचे दिए कमांड कार्य की परिभाषा, हाल के नेटवर्क प्रोफ़ाइल इवेंट और यह दिखाते हैं कि संसाधन उस खाते से पहुँच योग्य है या नहीं जिसके अंतर्गत कार्य चलता है। उन्हें हाथ से शुरू करने के बाद नहीं, असली पुनः कनेक्शन के बाद चलाएँ।
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoamiकार्य इतिहास में ऐसी प्रविष्टि होना जबकि कोई नेटवर्क इवेंट मेल न खाता हो, का अर्थ है ट्रिगर गलत है, क्रिया नहीं। यदि इवेंट दिखें और कार्य न चले, तो कार्य संभवतः ऐसे खाते के अंतर्गत चल रहा है जो संसाधन नहीं देख सकता, और खाते का आउटपुट ही सुराग है। मैपिंग अभी भी गायब रहते हुए पास होने वाली संसाधन जाँच कनेक्टिविटी नहीं, सत्र संदर्भ की ओर इशारा करती है। उन तीन अवलोकनों में से हर एक आपको अलग समाधान की ओर ले जाता है।
हर रन के लिए पता, संसाधन परिणाम और अंतिम परिणाम के साथ एक लॉग पंक्ति लिखें। अगली विफलता तब दिखाएगी कि कार्य जल्दी चला, गलत नेटवर्क पर चला, या बिलकुल नहीं चला।