Windows को .pbk फाइल कसको हो (र कसको होइन)
.pbk फाइल एउटा प्रोफाइल वा RRAS सर्भरको फोन बुक हो, पोर्टेबल VPN स्किमा होइन। मालिक, खण्ड र खुलासा गरिएको गुण पढ्नुहोस्।
खोज परिणामहरूले तपाईंलाई .pbk फाइल दिन्छन्, कुञ्जीका नामहरू परिचित देखिन्छन्, र स्पष्ट कदम भनेको यसलाई कुनै पनि Windows VPN का लागि पोर्टेबल स्किमा मान्नु हो। तर त्यस्तो होइन। ढाँचा एउटा मालिकको हुन्छ, र एउटै कुञ्जीले कुन मालिकले लेख्यो भन्ने आधारमा फरक अर्थ दिन्छ। पहिले दायरा पढ्नुले नै दस्तावेजीकरण अभ्यासलाई असमर्थित सम्पादनमा परिणत हुनबाट रोक्छ।
चार मालिक, चार फरक पाठक
चार फरक मालिकहरू उस्तै देखिने फाइलहरू लेख्छन्। प्रति-प्रयोगकर्ता मूल जडान हालको प्रयोगकर्ताको फोन बुकमा जान्छ, जबकि सबै-प्रयोगकर्ता जडान होस्टमा रहेको हरेक खाताले पढ्न सक्ने मेसिन-व्यापी भण्डारमा जान्छ। RRAS सर्भरले आफ्नै राउटिङ भूमिकाका लागि माग-अनुसार डायल कन्फिगरेसन राख्छ, र तेस्रो-पक्ष क्लाइन्टले विस्तार मात्र साझा गर्ने आफ्नै ढाँचा राख्न सक्छ। एउटै विस्तार, चार पाठक, नियमका चार सेट।
मिल्ने प्रदर्शन नामले दुई प्रविष्टिलाई एउटै बनाउँदैन, र तिनीहरूबीच कुञ्जी प्रतिलिपि गर्नु भनेको कुनै प्रबन्धकले कहिल्यै दस्तावेज नगरेको कुरालाई सम्मान गर्नेछ भन्ने मान्नु हो। मालिकले फाइल कसले बदल्न सक्ने पनि तय गर्छ: प्रति-प्रयोगकर्ता प्रोफाइल प्रयोगकर्ताको रोजाइ हो, मेसिन-व्यापी प्रोफाइल प्रशासनिक निर्णय हो, र सर्भरमा रहेको माग-अनुसार डायल प्रविष्टि आफ्नै परिवर्तन नियन्त्रणअन्तर्गतको राउटिङ कन्फिगरेसन हो। त्यसैले स्वामित्वको गल्ती ढाँचाको समस्या बन्नुअघि अनुमतिको समस्या बन्छ।
मालिक फाइल नभई जडान व्यवस्थापन गर्ने कम्पोनेन्टलाई हेरेर निर्धारण गर्नुहोस्। फाइल एउटा कलाकृति हो; कुन कुञ्जी कहिले पढ्ने भन्ने व्यवस्थापकीय कम्पोनेन्टले तय गर्छ। पहिले कलाकृति र पछि प्रबन्धक पढ्नु नै त्यो बाटो हो जहाँ मानिसहरू कुनै कुराले नसोध्ने क्षेत्र सम्पादन गर्न पुग्छन्।
प्रकाशित ढाँचाले तपाईंको फाइल वर्णन गर्न छोड्ने ठाउँ
RRAS व्यवस्थापन प्रोटोकलमा फोन बुक साधारण पाठ हो जुन व्यवस्थापन क्लाइन्टले लेख्छ र राउटिङ सेवाले पढ्छ, त्यसैले MS-RRASM विशिष्टता ले डेस्कटप प्रोफाइलका लागि नभई सर्भरका लागि माग-अनुसार डायल सेटिङहरू वर्णन गर्छ। संरचना त्यो भाग हो जुन समतल पठनले नष्ट गर्छ। एउटा प्रविष्टिमा धेरै मिडिया ब्लक हुन सक्छन्, प्रत्येकमा यन्त्र ब्लक हुन्छन् र तिनमा व्यक्तिगत नम्बरका ब्लक हुन्छन्। त्यसैले एउटै कुञ्जी एकभन्दा बढी ठाउँमा फरक अर्थसहित देखा पर्न सक्छ।
कुञ्जी त्यसको खण्ड र संस्करण-टिप्पणीसँगै पढ्नुहोस्, र डेस्कटप इन्टरफेसमा उही नामको चेकबक्सबाट कुनै मान अनुवाद नगर्नुहोस्। कागजातमा परिचित कुञ्जी भेट्नुले यसले असम्बन्धित मूल प्रोफाइलको हरेक क्षेत्र समेट्छ भनी प्रमाणित गर्दैन। खण्डका नियमहरू पनि डेस्कटप फोन बुकलाई सर्भर ढाँचामा पुनः लेख्ने अनुमति होइनन्।
| Owner | What reads the file | What a key means there |
|---|---|---|
| Per-user native connection | The user's own connection manager | A property of that user profile |
| All-user native connection | The machine-wide connection store | A property shared by everyone on the host |
| RRAS demand-dial | The RRAS service, using the documented hierarchy | A field inside a media, device or number section |
| Third-party client | That vendor's own parser | Whatever that vendor documents, if anything |
तालिका विशिष्टता होइन, पठन-सहायता हो: कुन पाठकलाई सोध्ने भनी यसले बताउँछ, र पाठकले क्षेत्रको अर्थ बताउँछ। जब त्यो पाठक तेस्रो-पक्ष पार्सर हो, तब इमानदार उत्तर यो हुन सक्छ कि कुनै पनि सार्वजनिक कागजातले यो क्षेत्रलाई नै दस्तावेज गर्दैन।
फाइललाई नभई Windows लाई सोध्नुहोस्
मूल जडानका लागि फाइल पढ्नुको सट्टा Windows बाट प्रोफाइल माग्नुहोस्, किनकि टाइप गरिएका गुणहरू नै दस्तावेज गरिएको सतह हुन् र समर्थित परिवर्तनले तिनैलाई मात्र बदल्छ। तलका दुई आदेशहरूले दुई मूल भण्डार छुट्टाछुट्टै पढ्छन्। यदि प्रोफाइल दुवै भण्डारमा छैन भने, यसलाई व्यवस्थापन गर्ने क्लाइन्टले मूल संयन्त्र प्रयोग गर्दैन र कुनै पनि मूल cmdlet ले यसको वर्णन गर्दैन।
Get-VpnConnection -Name 'Field Ops'
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType
तैनातीका लागि र निरीक्षणका लागि होइन, दस्तावेज गरिएको मार्ग नाम दिइएको स्किमासहितको व्यवस्थापित प्रोफाइल सेटिङ हो, पाठ वा बाइनरी ब्लबभित्रको सङ्ख्यात्मक सम्पादन होइन। प्रोफाइल परिभाषाले समर्थित सेटिङहरू वर्णन गर्छ; यसले प्रोफाइल निर्भर रहेका प्रमाणपत्र र निजी कुञ्जीहरू उपलब्ध गराउँदैन। दर्ता आफ्नै अधिकारसहितको छुट्टै प्रक्रिया हो, र फोन-बुक कुञ्जी बुझ्नुले कहिल्यै निजी कुञ्जी वितरण गरेको छैन। दुई मार्ग छुट्टाछुट्टै योजना बनाउनुहोस्, नत्र पहिलो प्रमाणपत्र तैनाती नै दोस्रो घटना बन्छ।
एउटा गुण, त्यसपछि यसको वरिपरिको जीवनचक्र
भण्डारण गरिएको मान लागू गरिएको मान होइन। स्वीकृत परिवर्तनपछि नयाँ जडान खोल्नुहोस् र प्रोफाइलले स्थापना गर्ने मार्गहरू, यसले वंशानुगत रूपमा पाउने रिजोल्भर नीति र यसले सक्षम गर्नुपर्ने कार्य जाँच्नुहोस्। पहिले नै खुलेको सत्र पुनः प्रयोग गर्दा पुराना सेटिङहरू परीक्षण हुन्छन् र झुटो नकारात्मक नतिजा आउँछ।
कुनै पनि कच्चा-फाइल काम अघि फाइल छेउमा प्रतिलिपि गर्नुहोस्, किनकि धेरै प्रविष्टि भएको फोन बुक साझा कलाकृति हो, र पूरै फाइल पुनः लेख्ने लक्षित सम्पादनको प्रभाव-त्रिज्या परिवर्तनभन्दा ठूलो हुन्छ। असम्बन्धित प्रविष्टिहरू अक्षत राख्नुहोस्, र नयाँ प्रमाणित नभएसम्म मूल संरक्षित कन्फिगरेसन राख्नुहोस्। यदि तपाईंसँग साँच्चै भएको मालिक र संस्करणका लागि कुनै अनिवार्य क्षेत्र दस्तावेज गरिएको छैन भने त्यसलाई खुला सहायता प्रश्नका रूपमा लेख्नुहोस्। अर्को मेसिनको फाइलबाट इन्कोडिङ बनाउनु नै त्यो बाटो हो जहाँ चलिरहेको प्रोफाइल कुनै सन्दर्भ बिन्दुविहीन डिबगिङ परियोजना बन्छ।
अनुशासन हरेक चरणमा एउटै हो: मालिकको नाम भन्नुहोस्, खण्डको नाम भन्नुहोस्, त्यसपछि समर्थित कार्यको नाम भन्नुहोस्। बाँकी सबै उद्धरण टाँसिएको अनुमान हो।