डीएफएस नेमस्पेस तक पहुंचने पर लंबा विराम


22

हमने हाल ही में साझा फ़ाइलों के लिए DFS का उपयोग करने के लिए अपने विंडोज नेटवर्क को माइग्रेट किया है। एक कष्टप्रद समस्या को छोड़कर, DFS अच्छी तरह से काम कर रहा है: उपयोगकर्ताओं को एक महत्वपूर्ण विलंब का अनुभव होता है जब वे DFS नामस्थान तक पहुँचने का प्रयास करते हैं जो उन्होंने कुछ समय से एक्सेस नहीं किया है। मैंने इस समस्या का निवारण करने की कोशिश की है, लेकिन अभी तक कोई सफलता नहीं मिली है, और मैं उम्मीद कर रहा था कि यहां कोई व्यक्ति समस्या को हल करने में मदद करने के लिए कुछ संकेत दे सकता है।

सबसे पहले, हमारे नेटवर्क पर कुछ पृष्ठभूमि:

नेटवर्क दो विंडोज़ 2008 डीसी और दो डीएनएस सर्वर (प्रत्येक डीसी पर एक) के साथ विंडोज 2008 कार्यात्मक स्तर सक्रिय निर्देशिका डोमेन का उपयोग करता है। नेटवर्क केवल DNS है - कोई जीत नहीं। सभी कंप्यूटर एक ही साइट पर स्थित हैं और गिगाबिट ईथरनेट द्वारा जुड़े हुए हैं। हमारे पास Windows 2008 मोड में लगभग 20 डोमेन-आधारित DFS नामस्थान हैं, और प्रत्येक DFS नामस्थान में दो Windows 2008 DFS नामस्थान सर्वर (सभी नामस्थानों के लिए समान दो सर्वर) हैं। सभी नाम स्थान सर्वर FQDN मोड में हैं और सभी फ़ोल्डर लक्ष्य उनके FQDN का उपयोग करके निर्दिष्ट किए गए हैं। सभी कंप्यूटर सर्विस पैक और पैच के साथ अद्यतित हैं।

वास्तविक फ़ोल्डर लक्ष्य (यानी एसएमबी हमारे डीएफएस फ़ोल्डर बिंदु को साझा करता है) कई फ़ाइल और एप्लिकेशन सर्वरों में बिखरे हुए हैं, सभी चल रहे विंडोज 2008 बार दो एप्लिकेशन सर्वर जो कि विंडोज 2003 R2 चलाते हैं, जिसमें कोई प्रतिकृति सेटअप नहीं है (जैसे सभी डीएफएस फ़ोल्डर्स वर्तमान में केवल एक फ़ोल्डर लक्ष्य है)।

समस्या पर कुछ और विस्तार:

नाम स्थान की पहुंच में देरी आमतौर पर 1 - 10 सेकंड लंबी होती है और ऐसा तब लगता है जब किसी विशेष कंप्यूटर ने लगभग पांच मिनट या उससे अधिक समय के लिए अनुरोध किए गए नाम स्थान तक नहीं पहुंच पाया है।

उदाहरण के लिए, यदि उपयोगकर्ता ने पाँच मिनट से अधिक समय तक \\ domain.name \ namepace1 \ एक्सेस नहीं किया है और Windows Explorer के माध्यम से \\ domain.name \ namepace1 \ एक्सेस करने का प्रयास करता है, तो एक्सप्लोरर विंडो 1 से 10 सेकंड के लिए समाप्त हो जाएगी। \\ domain.name \ namespace1 में मौजूद फ़ोल्डरों को फिर से शुरू और प्रदर्शित करना। यदि वे एक्सप्लोरर विंडो बंद करते हैं और पांच मिनट के भीतर \\ domain.name \ namepace1 \ फिर से एक्सेस करने का प्रयास करते हैं, तो सामग्री लगभग तुरंत प्रदर्शित की जाएगी - यदि वे पांच मिनट से अधिक समय तक प्रतीक्षा करते हैं तो यह 1 - 10 सेकंड के विराम के माध्यम से फिर से जाएगा।

एक बार "अंदर" नामस्थान सब कुछ अच्छा और तड़क-भड़क वाला है, यह धीमी गति से आने वाले नामस्थान का प्रारंभिक कनेक्शन है।

ब्राउज़िंग देरी विंडोज के सभी वेरिएंट को प्रभावित करती है जो हम उपयोग करते हैं (विंडोज 2008 x64 SP2, विंडोज 2003 R2 x86 SP2, विंडोज एक्सपी प्रो x86 एसपी 3) - यह विंडोज 2008 की तुलना में संभवतः विंडोज एक्सपी / 2003 में थोड़ा खराब है, लेकिन मैं अगर अंतर सिर्फ मनोवैज्ञानिक नहीं है, तो मुझे यकीन नहीं है।

अंतर्निहित फ़ोल्डर लक्ष्य तक पहुँचना सीधे किसी भी देरी का प्रदर्शन नहीं करता है - अर्थात यदि DFS द्वारा इंगित SMB शेयर सीधे (DFS को दरकिनार करके) एक्सेस किए जाते हैं तो कोई रोक नहीं है।

शूटिंग की शूटिंग के दौरान मैंने देखा कि हमारी सभी DFS जड़ों के लिए "कैश अवधि" 300 सेकंड - 5 मिनट पर सेट है। यह देखते हुए कि ठहराव को ट्रिगर करने के लिए समान समय की आवश्यकता है मुझे लगता है कि यह कैशिंग किसी तरह से संबंधित है, हालांकि मैं ग्राहक पर कैश्ड बिल्कुल अनिश्चित हूं और इसलिए 5 मिनट के बाद फिर से देखने की आवश्यकता है।

समस्या को हल करने की कोशिश में मैंने पहले ही प्रयास किया है / जाँच की है (सफलता के बिना):

  • डोमेन नियंत्रक दोनों पर dcdiag चलाएं - कोई समस्या नहीं मिली
  • बिना किसी समस्या के कुछ बुनियादी डीएनएस सर्वर की जांच की - मुझे नहीं पता कि डीएनएस सर्वरों की विस्तार से जांच कैसे की जाए, लेकिन मैं यह जोड़ना चाहूंगा कि नेटवर्क किसी अन्य अजीब व्यवहार का प्रदर्शन नहीं कर रहा है जो डीएनएस समस्या की ओर इशारा कर सकता है।
  • ग्राहकों और सर्वरों पर निष्क्रिय एंटी-वायरस
  • नाम स्थान के एक जोड़े से एक नामस्थान सर्वर को हटाना - कोई अंतर नहीं

तो यह है कि मैं कहाँ तक हूँ - और मैं विचारों से बाहर हूँ। क्या कोई सुझाव दे सकता है कि देरी का कारण क्या हो सकता है और / या मुझे आगे क्या प्रयास करना चाहिए?


3
एक ग्राहक पर Wireshark प्राप्त करें और "देरी" के दौरान ट्रैफ़िक को सूँघें। मेरी आंत कहती है कि आपको कुछ बताने जा रही है। अन्यथा, यह सिर्फ एक ब्लैक बॉक्स में घूर रहा है।
इवान एंडरसन

सुझाव के लिए धन्यवाद - मैं इसे एक कल दे दूँगा (मैं ऑस्ट्रेलिया में हूँ - 11pm अब) और देखो कि क्या यह कुछ भी स्पष्ट दिखाता है।
मैट

इस मैट पर कोई अपडेट?
JJ01

मैं इस प्रश्न के बारे में पूरी तरह से भूल गया: -एस दुर्भाग्य से हमने कोई प्रगति नहीं की है, बस इसके साथ रह रहे हैं। जब मुझे मौका मिलता है तो मैं यह देखने के लिए हमारे वातावरण में एक WinS सर्वर स्थापित करने का प्रयास करने जा रहा हूं कि क्या यह समस्या को ठीक करने में मदद करता है। असफल होने पर, मुझे समस्या के मूल कारण का पता लगाने और उसका पता लगाने के लिए विंडसरक (और इसके आउटपुट का विश्लेषण कैसे करना है) के बारे में अधिक जानने की आवश्यकता है।
मैट

जवाबों:


28

खैर, हम अंत में इस मुद्दे को अपने पर्यावरण में हल करने के लिए प्रकट होते हैं। दूसरों के लाभों के लिए, यहां हमने जो खोज की और हमने समस्या को कैसे निर्धारित किया:

विलंब से पहले / उसके दौरान / बाद में जो हो रहा था, उसके बारे में और अधिक जानकारी प्राप्त करने का प्रयास करने के लिए हमने एक ट्रैफ़िक मशीन पर Wireshark का उपयोग किया, ताकि नेटवर्क ट्रैफ़िक को कैप्चर / विश्लेषण करने के लिए क्लाइंट ने DFS शेयर तक पहुँचने का प्रयास किया।

इन कैप्चर ने कुछ अजीब दिखाया: जब भी देरी होती है, तो क्लाइंट से डीसी को भेजे जाने वाले डीएफएस अनुरोध के बीच, और डीसी से क्लाइंट को वापस आने वाले डीएफएस रूट सर्वर के लिए रेफरल, डीसी कई प्रसारण नाम भेज रहा था नेटवर्क को देखता है।

सबसे पहले, DC DOMAIN के लिए NetBIOS लुकअप (जहां DOMAIN हमारे पूर्व-Windows 2000 सक्रिय निर्देशिका डोमेन नाम है) प्रसारित करेगा। कुछ सेकंड बाद, यह DOMAIN के लिए LLMNR लुकअप प्रसारित करेगा । इसके बाद DOMAIN के लिए एक और प्रसारण NetBios लुकअप होगा। इन तीन लुकअप के प्रसारण के बाद (और मुझे लगता है कि समय समाप्त हो गया है) डीसी आखिरकार डीएफएस रूट सर्वर के लिए एक (सही) रेफरल के साथ क्लाइंट को जवाब देगा।

DOMAIN के लिए ये प्रसारण नाम लुकअप केवल तब भेजे जा रहे थे जब DFS शेयर खोलने में देर हो रही थी, और हम Wireshark कैप्चर से स्पष्ट रूप से देख सकते थे कि DC एक DFS रूट सर्वर को रेफरल नहीं दे रहा था जब तक कि सभी तीन लुकअप नहीं भेज दिए गए ( और (~ 7 सेकंड बीत गए)। तो, इन प्रसारण नाम लुकअप स्पष्ट रूप से हमारे देरी का कारण थे।

अब जब हमें पता था कि समस्या क्या है, तो हम यह पता लगाने की कोशिश करने लगे कि ये प्रसारण नाम लुकअप क्यों हो रहे थे। थोड़ा और Googling और कुछ ट्रायल-एंड-एरर के बाद, हमने अपना उत्तर पाया: हमने अपने डोमेन नियंत्रकों पर DfsDnsConfig रजिस्ट्री कुंजी को 1 पर सेट नहीं किया था, जैसा कि DNS-only वातावरण में DFS का उपयोग करते समय आवश्यक होता है।

जब हम मूल रूप से सेटअप डीएफएस हमारे वातावरण में हम किया था कैसे (जैसे एक DNS-केवल पर्यावरण के लिए डीएफएस कॉन्फ़िगर करने के लिए के बारे में विभिन्न लेख पढ़ने माइक्रोसॉफ्ट KB244380 और अन्य) और इस रजिस्ट्री कुंजी के बारे में जानते थे, लेकिन जब / कैसे करने के निर्देशों के misintepreted था इसका इस्तेमाल करें।

KB244380 कहता है:

DFSDnsConfig रजिस्ट्री कुंजी को प्रत्येक सर्वर से जोड़ा जाना चाहिए जो पूरी तरह से योग्य नामों को समझने के लिए सभी कंप्यूटरों के लिए DFS नामस्थान में भाग लेगा।

हमने सोचा कि इसका मतलब यह है कि रजिस्ट्री कुंजी को केवल डीएफएस नेमस्पेस सर्वर पर सेट किया जाना चाहिए , यह एहसास नहीं है कि यह डोमेन नियंत्रकों पर भी आवश्यक था। जब हमने अपने डोमेन नियंत्रकों पर DfsDnsConfig को 1 पर सेट किया (और "DFS नामस्थान" सेवा को पुनः आरंभ किया), तो समस्या गायब हो गई।

जाहिर है कि हम इस परिणाम से खुश हैं, लेकिन मैं यह भी जोड़ूंगा कि मैं अभी भी 100% आश्वस्त नहीं हूं कि यह हमारी एकमात्र समस्या है - मुझे आश्चर्य है कि अगर हमारे DCs में DfsDnsConfig = 1 को जोड़ा जाए तो समस्या को हल करने के बजाय केवल समस्या के आसपास काम किया है। । मैं यह पता नहीं लगा सकता कि डीएफएस रेफरल प्रक्रिया के दौरान, डीएनएसएफ रेफरल प्रक्रिया के दौरान भी डीसीएन डोमैन (डोमेन नेम में सर्वर के बजाय डोमेन नेम) को देखने की कोशिश क्यों कर रहे हैं, यहां तक ​​कि एक गैर-डीएनएस-एनवायरनमेंट में भी, और मुझे यह भी पता है कि मैं डोमेन नियंत्रक पर DfsDnsConfig = 1 को अन्य (सामान्य रूप से बहुत छोटा / सरल) DNS-केवल वातावरण सेट नहीं किया है और एक ही समस्या नहीं है। फिर भी, हमने अपनी समस्या हल कर ली है जिससे हम खुश हैं।

मुझे उम्मीद है कि यह उन लोगों के लिए मददगार है जो एक समान मुद्दे का सामना कर रहे हैं - और उन लोगों के लिए फिर से धन्यवाद जो रास्ते में सुझाव देते हैं।


3

यह DNS सर्वर नेटमास्क ऑर्डरिंग के कारण हो सकता है। हम हाल ही में सर्वर 2003 में आए थे। यह आपके वर्तमान सबनेटिंग पर निर्भर करता है।

उदाहरण।

साइट 1: आईपी सबनेट 10.0.0.0/24 साइट 2: आईपी सबनेट 10.0.1.0/24

साइट 2 में क्लाइंट आपके डोमेन आधारित नाम स्थान के लिए DNS क्वेरी बनाता है और साइट 1 में डिफ़ॉल्ट रूप से डीएफएस सर्वर दिया जाएगा क्योंकि DNS सर्वर को साइट आईपी सीमाओं के बारे में पता नहीं है। आपको अपने DNS सर्वर को यह बताने की जरूरत है कि किस आईपी पते का उपयोग करने के लिए सबनेट मास्क का उपयोग करें।

Http://support.microsoft.com/kb/842197 देखें


धन्यवाद, लेकिन हम केवल यहां एक साइट के साथ काम कर रहे हैं - सभी वर्कस्टेशन और सर्वर एक ही सबनेट पर भी हैं।
मैट

3

सक्रिय निर्देशिका टीम ब्लॉग में DFS विलंब के बारे में तीन भाग लेख है।

http://blogs.technet.com/b/askds/archive/2009/09/29/o-dfs-shares-where-art-thou-part-1-3.aspx

यह रेफ़रल प्रक्रिया पर मूल बातें शामिल करता है, और फिर दिखाता है कि देरी के वास्तविक कारण की खोज करने के लिए dfsUtil और dfsDiag सहित विभिन्न उपकरणों का उपयोग कैसे करें।

इसने मुझे मेरी समस्या का पता लगाने में मदद की। जो कि डोमेन उपयोगकर्ताओं के लिए शेयर निर्देशिका पर कोई पठन अनुमति नहीं है।

HTH, डैनियल


2

एक डीएनएस समस्या की तरह बदबू आ रही है लेकिन कुछ भी हो जाता है। मैंने पुराने FRS को बहुत पसंद किया क्योंकि डायग्नोस्टिक्स जैसे अल्ट्रासाउंड उपकरण उपयोगी थे: 7

क्या आपको लक्ष्य पर DFS प्रतिकृति घटना लॉग में कुछ भी मिलता है? (DFS हेल्थ रिपोर्ट ईवेंट लॉग से इसकी चेतावनी को आकर्षित करेगा)

बिना जीत के दौड़ना एक अच्छा लक्ष्य और सराहनीय है, हालांकि मैं इसके खिलाफ बहुत ज्यादा हूं अगर कोई पूर्व-विस्टा / 2008 विंडोज सिस्टम आसपास है क्योंकि चीजें हमेशा मेरे अनुभव में जीत के बिना अपेक्षित या तेज नहीं हैं - हालांकि यह वास्तव में है कोई बात नहीं होनी चाहिए।


हम डीएफएस प्रतिकृति का उपयोग नहीं कर रहे हैं, फ़ाइल शेयरों के अमूर्तकरण के लिए सिर्फ डीएफएस। आपकी टिप्पणियां केवल DNS-केवल वातावरण दिलचस्प हैं, हालांकि - हमारे बहुत सारे सर्वर विंडोज 2008 हैं, लेकिन सभी वर्कस्टेशन एक्सपी हैं और हमारे पास कुछ फेयरवॉन्ड 2003 सर्वर भी हैं। जब मेरे पास इसे आगे बढ़ाने का मौका होता है, तो मुझे लगता है कि मैं विन को स्थापित करने की कोशिश कर सकता हूं और देखें कि क्या मदद करता है।
मैट

1

क्लाइंट डीएफएस रेफरल को कैश करता है, यानी जब आप \ domain.name \ namepace दर्ज करते हैं तो यह कैश करेगा जो वास्तविक सर्वर domain.name को प्राप्त होता है। एक बार जब रेफरल कैश से समाप्त हो जाता है, तो क्लाइंट को मूल रूप से आपके डीएफएस टोपोलॉजी को फिर से "खोज" करना पड़ता है, इसलिए देरी हो रही है।

यहाँ देखें: http://technet.microsoft.com/en-us/library/cc758234(WS.10).aspx और यहाँ http://blogs.technet.com/filecab/archive/2006/01/20 / 417832.aspx आगे की जानकारी के लिए कि यह कैसे काम करता है।

संभव समाधान? इसके बारे में जाने का एक हैकी तरीका एक छोटा प्रोग्राम लिखना हो सकता है जो हर कुछ मिनटों में "जीवित" रहता है; उदाहरण के लिए, एक C प्रोग्राम जो फोपेन की पहली फाइल है, उसे ढूंढता है और तुरंत उसे फेक करता है। मैंने इसकी कोशिश नहीं की है या इसका परीक्षण नहीं किया है, और यदि आप इसे करने जा रहे हैं तो आपको निश्चित रूप से कुछ सावधान विचार देने की आवश्यकता होगी।


सामान्य डीएफएस रेफरल सेकंड के रूप में नहीं लेना चाहिए, हालांकि, जैसे पोस्टर संकेत कर रहा है।
इवान एंडरसन

धन्यवाद, रेफरल प्रक्रिया को समझने के लिए कम से कम बेहतर ढंग से उन लोगों के कल पढ़ने होंगे। हालांकि "समाधान" पसंद नहीं है: -S अगर मैं सिर्फ इसके आसपास काम करना चाहता था तो मैं कैश की अवधि को बहुत बड़ा मान सकता था, लेकिन मैं समस्या का "उचित" समाधान खोजना चाहता हूं।
मैट

1

हमारे पास एक समान-ध्वनि की समस्या है, जहां उपयोगकर्ताओं को एक डीएफएस शेयर पर मैप किए गए ड्राइव पर क्लिक करने और शेयर के भीतर फ़ोल्डरों को देखने और ब्राउज़ करने में सक्षम होने के बीच देरी (एक मिनट तक) का अनुभव होगा।

उपयोगकर्ताओं को एक ही वॉल्यूम पर एक अलग डीएफएस शेयर के लिए मैप किए गए होम ड्राइव भी थे, और वहां फ़ोल्डर्स तक पहुंचने में कोई देरी नहीं हुई।

दोनों के बीच का अंतर एक्सेस-आधारित एन्यूमरेशन (ABE) है - समस्या शेयर ने इसे सक्षम किया है (यह उपयोगकर्ताओं के लिए एक सामान्य ड्राइव है, हजारों फ़ोल्डरों के साथ - ABE का अर्थ है कि उपयोगकर्ता केवल उन फ़ोल्डरों को देखते हैं जिनके पास उनकी अनुमति है)।

ABE को अक्षम करने से समस्या पूरी तरह से दूर हो गई। जाहिर है कि यह एक समाधान नहीं है क्योंकि उपयोगकर्ता तब सभी फ़ोल्डरों को देखते हैं, उन्हें भ्रमित करते हैं। मैंने एक अस्थायी उपाय के रूप में कुछ स्पेयर डिस्क के साथ सर्वर पर डीएफएस शेयर को दोहराया है, और यहां तक ​​कि इस नए लक्ष्य पर सक्षम एबीई के साथ, देरी हो गई है।

समस्या सर्वर 2k3R2 है, और इसमें 150 से अधिक दिनों (!) का अपटाइम है, इसलिए यह रिबूट होने वाला है और CHKDSK को आपत्तिजनक मात्रा में चलाता है। अगर समस्या का कोई फर्क पड़ता है तो मैं यहाँ वापस पोस्ट करूँगा। नया लक्ष्य 2k8 सर्वर पर है।


धन्यवाद, लेकिन हम ABE (अभी तक) का उपयोग नहीं कर रहे हैं, इसलिए यह समस्या नहीं है।
मैट

1

dfsutil / spcflush और dfsutil / pktflush एक बहु साइट नेटवर्क में भी एक समाधान हो सकता है सुनिश्चित करें कि होम साइट का DFS लिंक लोकल सर्वर बन रहा है और कैश से नहीं।


1

मुझे पता है कि मूल पोस्टर WINS का उपयोग नहीं कर रहा था, लेकिन मैं दूसरों के लाभ के लिए पोस्ट कर रहा हूं क्योंकि हमने इस पोस्ट का उपयोग सबसे अधिक समान समस्या को हल करने में मदद करने के लिए किया था। हमारे लिए यह समाप्त हो गया कि किसी ने डोमेन के समान नाम के साथ अपने कार्य केंद्र का नाम तय किया। इसलिए, हर बार डीसी ने डीएफएस रेफरल के लिए डोमेन नाम पर एक लुकअप किया था, यह उस कार्य केंद्र में हल करना चाहता था और सेकंड के विलंब से काफी बहु-10 का कारण होगा। एक DC में इंगित करते हुए WINS में एक स्थिर 20 प्रविष्टि रखी गई थी और इससे समस्या हल हो गई है। यदि आपके पास कोई WINS नहीं था, तो आप 20 नाम पाने के लिए DC को इंगित की गई LMHOSTS फ़ाइल में मशीन के नाम के रूप में डोमेन नाम रखकर प्रयोग कर सकते हैं, और LMHOSTS को प्राथमिकता देने के लिए नेटवर्क्स के नामों को हल करने के लिए पहले स्थान पर होना चाहिए।


1

http://technet.microsoft.com/en-us/library/cc780950(v=ws.10).aspx इस पृष्ठ में वास्तव में डोमेन नियंत्रक और DFSN दोनों का उल्लेख है, यदि यह मदद करता है।

DFS डोमेन नियंत्रक और रूट सर्वर रजिस्ट्री प्रविष्टियाँ

निम्नलिखित रजिस्ट्री प्रविष्टियों के तहत स्थित हैं

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs 

रूट सर्वर और डोमेन नियंत्रकों पर। सभी प्रविष्टियाँ REG_DWORD हैं।


1

इसलिए मैंने अपनी खोज में इस लेख का उपयोग किया। मैंने सब कुछ सेट किया और अभी भी मुद्दे थे। कई दिनों तक इस समस्या को देखने और 'Microsoft' सब कुछ छोड़कर मैंने यह अनुमान लगाया कि यह नेटवर्क से संबंधित था। हमारे वैन त्वरक निकला मुद्दा था। मेरे पास हमारे नेटवर्किंग कंट्रोलर के लिए हमारे नेटवर्किंग लोग त्वरण को बंद कर चुके थे और सब कुछ बेहतर हो गया।


1

बहुत सारे नियंत्रक थे, इसलिए एक स्क्रिप्ट ( dnsdfs.cmd servername):

dfsutil server registry dfsdnsconfig set %1
sc \\%1 stop dfs
sc \\%1 start dfs

0

आप उल्लेख करते हैं कि आपके पास 20 डीएफएस सर्वर अभी भी यह उल्लेख करने में विफल हैं कि सभी सर्वर एक ही सुविधा में हैं।

यदि ये सर्वर एक ही सुविधा में नहीं हैं और एक-दूसरे की साइट का अपना डोमेन है, तो आप सुनिश्चित कर सकते हैं कि क्लाइंट विफल होना सक्षम है।


2
हमारे पास 20 डीएफएस / नेमस्पेस / हैं, न कि 20 डीएफएस / सर्वर /। केवल 2 DFS सर्वर, दोनों एक ही साइट (और सबनेट) में।
मैट

0

उन लोगों के लिए जो एक Google खोज के माध्यम से यहां समाप्त होते हैं और जिनके पास एक ही समस्या है ...

पहले जांच लें कि आपके नेमस्पेस में सभी लिंक उपलब्ध हैं और अच्छे हैं। मेरे मामले में यही हुआ है, नाम सर्वर में लिंक अभी भी था जो नीचे था, इसलिए DNS खोलने पर लंबा विराम इसलिए था क्योंकि यह उस सर्वर को खोज रहा था और विफल हो रहा था। एक बार जब मैंने डीएफएस में उस लिंक को निष्क्रिय कर दिया तो लंबा विराम चला गया।


-1

सत्यापित करें कि प्रामाणिक उपयोगकर्ता समूह के पास आपके द्वारा मैप किए गए रूट निर्देशिका की सामग्री को सूचीबद्ध करने के लिए एक्सेस है। उदाहरण के लिए यदि x: ड्राइव को \ domain.local \ दिव्यांग \ मार्केटिंग में मैप किया जाता है, तो उपयोगकर्ता को \ domain.local \ विभागों के लिए सूची अनुमति की आवश्यकता होगी। 2008/2012 में, आप उन्नत अनुमतियों के तहत निर्दिष्ट कर सकते हैं कि यह "केवल इस फ़ोल्डर" पर लागू होता है ताकि उन्हें किसी भी उप फ़ोल्डर की सामग्री को सूचीबद्ध करने की अनुमति न हो जो अनुमतियाँ विरासत में मिली हों।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.