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 फिल्डले नै तपाईंले तीनमध्ये कुन बनाउनुभयो भनेर बताउँछ। यदि लगइन अघि जडान हुनैपर्छ भने, प्रति-प्रयोगकर्ता प्रोफाइल स्टोर सुधार्न गलत तह हो।