Windows Pro पर डिवाइस टनल? संस्करण मैट्रिक्स देखें
तैनात प्रोफ़ाइल योग्यता का प्रमाण नहीं है। टनल को डीबग करने से पहले संस्करण मैट्रिक्स, CSP नोड और साइन-इन-पूर्व पूर्वापेक्षाओं की तुलना करें।
प्रोफ़ाइल लैपटॉप पर पहुँचती है, VPN सेटिंग्स पृष्ठ उसे दिखाता है, और फिर भी डिवाइस टनल साइन-इन स्क्रीन पर कभी कनेक्ट नहीं होती। Windows Pro पर यह अक्सर कॉन्फ़िगरेशन त्रुटि नहीं होती। मूल डिवाइस टनल संस्करण के अनुसार लाइसेंस की जाती है, और साइन-इन के बाद काम करने वाली उपयोगकर्ता टनल एक अलग क्षमता साबित करती है। प्रमाणपत्र डीबग करने से पहले आवश्यकता पढ़ें।
लक्षण किसी के साइन इन करने से पहले दिखाई देता है
उपयोगकर्ता टनल साइन-इन के बाद उपयोगकर्ता के संदर्भ में कनेक्ट होती है, इसलिए वह Pro पर सामान्य रूप से काम करती है। डिवाइस टनल को किसी भी उपयोगकर्ता के लॉग इन करने से पहले मशीन प्रमाणपत्र और IKEv2 का उपयोग करके मशीन कनेक्टिविटी स्थापित करनी चाहिए। ये जीवनचक्र के अलग-अलग चरण हैं, एक ही प्रोफ़ाइल के दो नाम नहीं।
अयोग्य संस्करण पर प्रोफ़ाइल अभी भी वितरित और सूचीबद्ध की जा सकती है, लेकिन साइन-इन-पूर्व कनेक्शन दिखाई नहीं देता। साइन-इन के बाद उपयोगकर्ता टनल पूरी तरह काम कर सकती है, जिससे खाते के मालिक द्वारा की जाने वाली हर जाँच में तैनाती स्वस्थ दिखती है। विफलता साइन इन किए गए सत्र के भीतर से अदृश्य है।
प्रोफ़ाइल को सभी उपयोगकर्ताओं के लिए उपलब्ध कराना यह बदलता है कि इसे कौन उपयोग कर सकता है। यह प्रमाणीकरण संदर्भ को उपयोगकर्ता से मशीन में नहीं बदलता, इसलिए यह उपयोगकर्ता टनल को डिवाइस टनल में नहीं बदल सकता। अंतर प्रमाणीकरण संदर्भ का है, प्रोफ़ाइल की दृश्यता का नहीं।
मैट्रिक्स पढ़ें, केवल CSP नोड नहीं
Microsoft का Windows 11 सुविधा मैट्रिक्स Enterprise और Education के लिए मूल Always On VPN डिवाइस टनल सूचीबद्ध करता है। VPNv2 कॉन्फ़िगरेशन सेवा प्रदाता अलग से DeviceTunnel नोड का दस्तावेज़ीकरण करता है जिसकी प्रयोज्यता में Pro शामिल है, और उस पंक्ति को अक्सर इस बात के प्रमाण के रूप में उद्धृत किया जाता है कि सुविधा काम करती है। कॉन्फ़िगरेशन सतह और सुविधा लाइसेंसिंग अलग प्रश्नों के उत्तर देते हैं: एक कहता है कि सेटिंग व्यक्त की जा सकती है, दूसरा कहता है कि संस्करण उस क्षमता का हकदार है।
खरीद रिकॉर्ड पर भरोसा करने के बजाय प्रभावी संस्करण और बिल्ड की पुष्टि करें। प्रबंधित सक्रियण, चल रहा अपग्रेड या फिर से बनाई गई छवि मशीन को एसेट सूची में बताए गए संस्करण से भिन्न संस्करण पर छोड़ सकते हैं:
winver
DISM /online /get-currentedition
Get-ComputerInfo | Select-Object WindowsProductName, WindowsEditionId, OsBuildNumberयदि आउटपुट Pro कहता है, तो मूल डिवाइस टनल उस मशीन के लिए दस्तावेज़ीकृत सुविधा सेट से बाहर है। इस निष्कर्ष के लिए प्रोफ़ाइल परिवर्तन की आवश्यकता नहीं है और उससे यह ठीक नहीं होगा। कुछ और बदलने से पहले यह निष्कर्ष दर्ज करें।
सुविधा ध्वज के पीछे चार पूर्वापेक्षाएँ
संस्करण द्वार है, और शेष आवश्यकताएँ समझाती हैं कि योग्य संस्करण वाली मशीन अभी भी क्यों विफल होती है। उन्हें क्रम में जाँचें, क्योंकि प्रत्येक एक ही मौन परिणाम दे सकता है। एक पंक्ति छोड़ने से उसके नीचे की पंक्तियों पर किया गया प्रयास बर्बाद होता है। संस्करण पहले आता है, इसका कारण है।
| Prerequisite | How to verify | Common failure |
|---|---|---|
| Edition and build | DISM /online /get-currentedition | Pro image with an Enterprise asset record |
| Join state | Domain membership in system information | Microsoft Entra join treated as domain join |
| Machine certificate | Certificate store in the local machine context | Certificate issued to the user store |
| Profile context | Provisioned through the machine channel | Delivered as a user tunnel profile |
प्रमाणपत्र जाँच वही है जिसे लोग छोड़ देते हैं। निजी कुंजी मशीन स्टोर में मौजूद होनी चाहिए और साइन-इन से पहले सिस्टम संदर्भ द्वारा उपयोग करने योग्य होनी चाहिए, जो उस स्टोर से अलग है जो उपयोगकर्ता अपने प्रमाणपत्र संवाद में देखता है:
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.HasPrivateKey } | Select-Object Subject, NotAfterउपयोगकर्ता के स्टोर में सही दिखने वाला प्रमाणपत्र मशीन स्टोर से पूरी तरह अनुपस्थित हो सकता है। तब लॉगिन स्क्रीन आने से पहले डिवाइस टनल प्रमाणीकरण में विफल हो जाती है, और प्रोफ़ाइल का दोबारा आयात इसे नहीं बदलता। वह स्टोर जाँचें जिसका उपयोग सेवा करती है, वह नहीं जो उपयोगकर्ता देखता है।
SYSTEM के रूप में चलने वाला निर्धारित कार्य वह सुविधा नहीं है
एक समाधान प्रचलित है जो SYSTEM के रूप में चलने वाले निर्धारित कार्य से VPN प्रोफ़ाइल शुरू करता है, जिससे बूट के थोड़ी देर बाद टनल दिखाई देती है। यह मूल डिवाइस टनल नहीं है। टास्क इंजन अलग बिंदु पर शुरू होता है, कनेक्शन सेवा खाते द्वारा शुरू की गई उपयोगकर्ता-मोड प्रोफ़ाइल है, और जीवनचक्र उस मशीन-प्रमाणित टनल से मेल नहीं खाता जो साइन-इन स्क्रीन पर मौजूद होनी चाहिए।
यह सामान्य परीक्षण पास कर सकता है, क्योंकि जब कोई लॉग इन करके जाँचता है तब तक टनल चालू होती है। वह सफलता बूट और कार्य के बीच देरी मापती है, साइन-इन-पूर्व कनेक्टिविटी नहीं, और यह उस अवधि में मशीन को टनल के बिना छोड़ देती है जिसे सुविधा को कवर करना था।
उत्पादन के लिए समाधान को असमर्थित मानें। यदि कोई डिज़ाइन उस पर निर्भर है, तो आवश्यकता संभवतः लॉगिन-पूर्व कनेक्शन है, जो चर्चा को फिर संस्करण की योग्यता पर ले आती है।
तकनीक से पहले आवश्यकता चुनें
आवश्यकता एक वाक्य में लिखें: किसी भी उपयोगकर्ता के साइन इन करने से पहले डिवाइस को किसी नामित संसाधन तक पहुँचना चाहिए, या उपयोगकर्ता को साइन-इन के बाद पहुँच चाहिए। यदि दूसरा वाक्य सत्य है, तो Pro पर Always On उपयोगकर्ता टनल समर्थित डिज़ाइन है और डिवाइस टनल अनावश्यक जटिलता है।
यदि पहला वाक्य सत्य है, तो संस्करण कठोर द्वार है। योग्य संस्करण या संगठन द्वारा समर्थित दस्तावेज़ीकृत लॉगिन-पूर्व आर्किटेक्चर चुनें, और उस क्षमता के आसपास प्रोफ़ाइल और प्रमाणपत्र बनाने से पहले लाइसेंस परिवर्तन की योजना बनाएँ जिसे मशीन चला नहीं सकती।
तैनाती नोट्स में संस्करण, जॉइन स्थिति, प्रमाणपत्र स्थान और प्रावधान चैनल दर्ज करें। तब अगला इंजीनियर उसी प्रोफ़ाइल समस्या-निवारण को ऐसी मशीन पर दोहराने के बजाय जो कभी कनेक्ट नहीं होती, कुछ ही मिनटों में योग्यता की पुष्टि कर सकेगा।