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 फील्डच तुम्हाला तीनपैकी कोणते बांधले हे सांगते। लॉगिनपूर्वी कनेक्टिव्हिटी असणे आवश्यक असल्यास, प्रत्येक-वापरकर्ता प्रोफाइल स्टोअर दुरुस्त करण्यासाठी चुकीचा स्तर आहे।