Microsoft कोर इन्फ्रास्ट्रक्चर माइग्रेशन। भाग 1

परिचय।

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

मैं वास्तविक अवसंरचना में प्रवासन की विशेषताओं के बारे में बात करने के लिए इस विषय को एक बड़ी मात्रा में प्रकट करना चाहूंगा। विभिन्न सूचना प्रणालियों के संचालन की बारीकियों को ध्यान में रखा जाएगा कि ऐसी प्रणालियों को किस क्रम में माइग्रेट करने की आवश्यकता है।

सामग्री की समीक्षा करने के लिए एक लेख पर्याप्त नहीं है (या यह एक बहुत बड़ा लेख होगा), इसलिए कई लेख होंगे। सामग्री की अंतिम मात्रा अभी तक ज्ञात नहीं है। मैं जहां तक ​​संभव हो लिखूंगा, मैं इस प्रक्रिया में देरी न करने की कोशिश करूंगा।

हम बुनियादी ढांचे के रूप में क्या विचार करेंगे, और इसमें क्या शामिल होगा?

• सक्रिय निर्देशिका दाईं ओर, एडी को अंतर्निहित बुनियादी ढांचे में एक प्रमुख घटक कहा जा सकता है;
• डीएनएस;
• डीएचसीपी;
• WINS;
• फ़ाइल सर्वर;
• प्रिंट सर्वर;
• टर्मिनल सर्वर और टर्मिनल सर्वर फार्म;
• डीएफएस और उसके तत्व;

अब अधिक से अधिक संगठन एकीकृत संचार के साधन के रूप में एक्सचेंज सर्वर का उपयोग कर रहे हैं। एक्सचेंज सीधे सक्रिय निर्देशिका पर निर्भर है, और निर्देशिका सेवा माइग्रेशन निश्चित रूप से प्रभावित करेगा कि एक्सचेंज उपयोगकर्ता कैसे काम करते हैं। सक्रिय निर्देशिका माइग्रेशन दस्तावेज़ है, लेकिन यह दस्तावेज़ Exchange के साथ AD माइग्रेशन प्रक्रिया का वर्णन नहीं करता है। बदले में, अन्य दस्तावेज़ एक्सचेंज माइग्रेशन का वर्णन करते हैं, लेकिन इसे सक्रिय निर्देशिका माइग्रेशन के साथ संयोजन में नहीं माना जाता है। उसी तस्वीर के बारे में मैंने परियोजनाओं पर देखा जिसमें कई आर्किटेक्ट ने भाग लिया - एक ईस्वी पर, दूसरा एक्सचेंज पर। अक्सर उनके कार्यों को समन्वित नहीं किया गया था - दो प्रणालियों का प्रवास कुछ अलग-थलग था, संयुक्त प्रवास की विशेषताओं को ध्यान में नहीं रखा गया था। यह पता चला कि एक प्रणाली (वास्तुकार) दूसरे (दूसरे) के साथ हस्तक्षेप करती है।

Microsoft SQL सर्वर माइग्रेशन की कुछ विशेषताएं हैं। हम उन्हें प्रवास में शामिल करेंगे।
हम प्रवास पर क्या विचार करेंगे? हम प्रवासन को लक्ष्य वन के लिए एक या कई जंगलों से संसाधनों के हस्तांतरण के रूप में मानते हैं। ऐसा मॉडल सबसे अधिक बार अभ्यास में पाया जाता है।

प्रवासन की प्रक्रिया केवल आधी लड़ाई है (सबसे कम संभावना है)। प्रवासन एक जटिल, लंबी प्रक्रिया है, इसमें समय के साथ वितरित कई कार्य शामिल हैं, जिनके कार्यान्वयन से कुछ परिणाम प्राप्त होंगे, लक्ष्य प्राप्त होंगे। मुझे वास्तव में एक परियोजना की परिभाषा कहा जाता है। एक परियोजना के लिए एक विशिष्ट दृष्टिकोण की आवश्यकता होती है। कई परियोजना प्रबंधन के तरीके हैं, विषय बड़ा है, इस लेख पर विचार नहीं किया जाएगा। MSF (Microsoft सॉल्यूशन फ्रेमवर्क) पद्धति में परियोजना प्रबंधन पर अच्छी सिफारिशें दी गई हैं। कुछ का मानना ​​है कि यह मॉडल केवल डेवलपर्स के लिए उपयुक्त है और बुनियादी ढांचा परियोजनाओं पर लागू नहीं होता है। वास्तव में ऐसा नहीं है। कार्यप्रणाली की सामग्री बुनियादी ढांचा परियोजनाओं के लिए अच्छी तरह से अनुकूल है, केवल थोड़ा सार करना आवश्यक है। यह कार्यप्रणाली "कैसे और क्या करना है" का वर्णन नहीं करेगी, इसमें परियोजना प्रबंधन के लिए सख्त नियम नहीं होंगे, लेकिन यह मूल्यवान सलाह प्रदान करता है जो आपको केवल आईटी ही नहीं, बल्कि किसी भी परियोजना को पूरा करने में मदद करेगा।

इसके अलावा, मानक, उदाहरण के लिए, GOSTs, डिजाइन में मदद करेंगे।
इनमें से, आपको कुछ सिफारिशों का चयन करने की भी आवश्यकता है जो परियोजना को सफलतापूर्वक पूरा करने में आपकी मदद करेंगे। आप यहाँ स्वचालित सिस्टम के लिए GOSTs पा सकते हैं।
उदाहरण के लिए, मैंने अपने लिए एक निश्चित तकनीक विकसित की, जो GOSTs और MSF पद्धति का एक संकर है। मैंने इसे अभ्यास में डाल दिया।

परियोजना प्रबंधन पर कुछ सिफारिशें, और विशेष रूप से परियोजना टीम प्रबंधन पर, स्ट्रैसपुप की पुस्तक "सी ++ प्रोग्रामिंग लैंग्वेज", दूसरे और तीसरे संस्करण से ली जा सकती है। इस पुस्तक में डिजाइन पर एक अलग अध्याय है।

Microsoft प्रोजेक्ट प्रोजेक्ट की प्रगति को नियंत्रित करने में आपकी सहायता करेगा। ए। गुलटेव की एक अच्छी किताब है। Microsoft प्रोजेक्ट में प्रोजेक्ट प्रबंधन। मैं आपको इसे पढ़ने की सलाह देता हूं।

स्रोत डेटा

हमारे पास प्रारंभिक डेटा क्या है?

हमारे पास एक वन और कई डोमेन से युक्त एक प्रारंभिक बुनियादी ढांचा है।
रूट डोमेन नाम source.com/SOURCE है। चाइल्ड डोमेन child1.source.com/CHILD1 है। Source.com में डोमेन नियंत्रकों का संस्करण SP2 के साथ Windows Server 2003 है, चाइल्ड 1 में - एसपी 4 के साथ विंडोज 2000 सर्वर। कई उपयोगकर्ता डोमेन में काम करते हैं। वर्कस्टेशन - 2000, एक्सपी, विस्टा, विंडोज 7. विंडोज 2000 सर्वर, विंडोज सर्वर 2003 / 2008R1 / 2008R2 सर्वर हैं।

प्रत्येक डोमेन में SP2 के साथ Exchange 2003 सर्वर स्थापित है। यदि Exchange सर्वर पर SP2 स्थापित नहीं है, तो उपयोगकर्ता मेलबॉक्सों को माइग्रेट करने से पहले आपको यह करना होगा। Exchange 2010 केवल Exchange Server 2003 SP2 और Exchange Server 2007 SP2 से मेलबॉक्स माइग्रेशन का समर्थन करता है।

Exchange Server 2010 (या Exchange 2007) के लिए मेल माइग्रेट करते समय डोमेन नियंत्रक संस्करणों के लिए कुछ आवश्यकताएँ होती हैं। इन सुविधाओं के बारे में थोड़ी देर बाद।
हमने पहले ही लक्ष्य ढाँचे को तैयार कर लिया है और इसे लागू भी कर दिया है। Target.com/TARGET डोमेन लक्ष्य के बुनियादी ढांचे के रूप में कार्य करेगा। Windows Server 2008 R2 डोमेन नियंत्रकों का संस्करण।
Exchange Server 2010 को एक अलग सर्वर पर स्थापित किया गया है। इस सर्वर पर सभी भूमिकाएँ स्थापित की गई हैं, विशेष रूप से हब, कैस और मेलबॉक्स भूमिकाएँ। स्रोत डोमेन में से एक सर्वर अब बाहरी मेल को संसाधित करने के लिए जिम्मेदार है। माइग्रेशन के बाद, नए इन्फ्रास्ट्रक्चर में एक और सर्वर, एज ट्रांसपोर्ट भूमिका के साथ एक्सचेंज सर्वर 2010, इस भूमिका को लेगा।

स्रोत डोमेन में हमारे पास विभिन्न प्रकार के सर्वर भी होंगे। हमें उन्हें नए बुनियादी ढांचे में भी स्थानांतरित करना होगा। सर्वर माइग्रेशन के बारे में थोड़ा बाद में।

एकता।

प्रवासन एक लंबी प्रक्रिया है और इस प्रक्रिया का तात्पर्य दो प्रणालियों के दीर्घकालिक सह-अस्तित्व से है - पुराना और नया।
इसलिए, हमें अपने मौजूदा बुनियादी ढांचे को लक्ष्य के साथ एकीकृत करने की आवश्यकता है।

नाम का संकल्प।

एकीकरण कहाँ से शुरू करें? इन्फ्रास्ट्रक्चर के बीच नाम समाधान स्थापित करने के साथ सर्वश्रेष्ठ। हमें गैर-आप्रवासित संसाधनों के नामों को हल करने में सक्षम होने के लिए अप्रत्यक्ष संसाधनों की आवश्यकता है, और इसके विपरीत। विंडोज नेटवर्क पर सबसे लोकप्रिय नाम रिज़ॉल्यूशन तंत्र DNS और NETBIOS हैं।
हम मानते हैं कि DNS सर्वर डोमेन नियंत्रक पर तैनात हैं। ये DNS सर्वर अपने विभाजन और ज़ोन _msdcs.root_domain_wood_domain के लिए क्षेत्र की सेवा करते हैं। क्षेत्र सक्रिय निर्देशिका में एकीकृत हैं।
एक नियम के रूप में, इन्फ्रास्ट्रक्चर के बीच केवल DNS नामों का संकल्प ही पर्याप्त है।

इस इंटरैक्शन को कॉन्फ़िगर करने के कई तरीके हैं: फ़ॉरवर्डिंग, सेकेंडरी ज़ोन, स्टब ज़ोन।

पहली विधि पर विचार करें - अग्रेषण:

सामान्य तौर पर, कुछ भी हमें इस तंत्र का उपयोग करने से रोकता है। सबसे पहले, हम स्रोत डोमेन में लक्ष्य डोमेन के लिए अग्रेषण कॉन्फ़िगर करते हैं। अग्रेषण के लिए, हम लक्ष्य डोमेन के निकटतम DNS सर्वरों को इंगित करते हैं। आने का क्या मतलब है? एक नियम के रूप में, एक बहु-डोमेन वातावरण में, एक क्षेत्रीय साइट के लिए एक अलग डोमेन आवंटित किया जाता है (हमारे मामले में, यह child1.source.com है)। अब, निश्चित रूप से, वे इस तरह के एक मॉडल से दूर जाने और एकल-डोमेन मॉडल पर आगे बढ़ने की कोशिश कर रहे हैं। लेकिन एकल-डोमेन मॉडल को किसी भी नियम के रूप में नहीं मानते हैं। कभी-कभी यह आपके अनुरूप नहीं हो सकता है। यह सब आवश्यकताओं पर निर्भर करता है। जब किसी नए डोमेन पर माइग्रेट किया जा रहा है, तो कंप्यूटर स्थानीय डोमेन नियंत्रकों पर, उसी भौतिक साइट के डोमेन नियंत्रकों पर स्रोत फ़ॉरेस्ट में पंजीकृत करेगा (बशर्ते कि हमने DNS क्लाइंट नेटवर्क कार्ड के नेटवर्क कॉन्फ़िगरेशन को सही ढंग से कॉन्फ़िगर किया है; )। इसलिए, यह विशेष रूप से इन स्थानीय डोमेन नियंत्रकों को अग्रेषित करने के लिए कॉन्फ़िगर करना सही होगा।
लक्ष्य डोमेन में, हम वही काम कर रहे हैं - हम निकटतम DNS सर्वरों के बीच स्रोत डोमेन के लिए अग्रेषण कॉन्फ़िगर करते हैं।

यदि स्रोत DNS सर्वर Windows 2000 हैं, तो आपको द्वितीयक क्षेत्रों का उपयोग करना चाहिए या लक्ष्य डोमेन के DNS सर्वरों के लिए वैश्विक स्थानान्तरण के साथ संयोजन में नामों को हल करने के तरीके पर विचार करना चाहिए।
विंडोज सर्वर 2008 से शुरू करना, अब DNS सर्वर के बीच अग्रेषण रिकॉर्ड को दोहराने के लिए संभव है। आप इस तंत्र का उपयोग कर सकते हैं ताकि कई बार एक ही काम न करें।

दूसरा तंत्र द्वितीयक क्षेत्रों का उपयोग है:

यहां हम स्रोत और लक्ष्य डोमेन के सर्वर के बीच ज़ोन फ़ॉरवर्डिंग सक्षम करते हैं। द्वितीयक क्षेत्र बनाएँ: स्रोत DNS सर्वर पर, लक्ष्य डोमेन के लिए द्वितीयक क्षेत्र, स्रोत डोमेन के लिए लक्ष्य क्षेत्र पर। मास्टर सर्वर के रूप में हम निकटतम DNS सर्वर का उपयोग करते हैं। परिवर्तनों के लिए अलर्ट सेट करें। अलर्ट से पहले परिवर्तन की संख्या 1 है।

तीसरा तरीका स्टब जोन का उपयोग करना है:

यह कार्यक्षमता विंडोज सर्वर 2003 में दिखाई दी। स्टब ज़ोन का उपयोग करके, हम आधिकारिक DNS सर्वरों के बारे में जानकारी प्राप्त कर सकते हैं - इस क्षेत्र में काम करने वाले सर्वरों के एनएस और ए रिकॉर्ड। इसके अलावा, यह जानकारी भी गतिशील रूप से अपडेट की जाएगी।
सामान्य तौर पर, विधि उत्कृष्ट है, लेकिन हमारे उदाहरण के लिए यह केवल आंशिक रूप से उपयुक्त है। चाइल्ड 1 डोमेन के DNS सर्वरों को सभी target.com डोमेन DNS सर्वरों के लिए NS / A रिकॉर्ड प्राप्त होंगे (हम DisallowNSAutoCreation के साथ मामलों पर विचार नहीं करेंगे)। नाम समाधान के लिए, वे इन एनएस सर्वरों में से एक का भी उपयोग करेंगे। जब हम कंप्यूटर को एक नए डोमेन में स्थानांतरित करते हैं, तो यह निकटतम DNS सर्वर "नए" पर पंजीकृत होगा। फिर भी गैर-आप्रवासी कंप्यूटर पुराने DNS सर्वरों तक पहुंच बनाएंगे, और बदले में नए डोमेन से कुछ DNS सर्वरों की ओर रुख करेंगे। कौन सा? क्या माइग्रेटेड कंप्यूटर का नया A रिकॉर्ड इस तरह के DNS सर्वर को दोहराने का प्रबंधन करेगा? इस सवाल का जवाब देना मुश्किल है। इसलिए, हमारे कॉन्फ़िगरेशन के लिए पुराने डोमेन से नए तक स्टब ज़ोन, काम नहीं करेगा। लेकिन विपरीत दिशा में, हम उनका उपयोग कर सकते हैं।

विंडोज सर्वर 2008 आर 1 के साथ शुरू, हमारे पास DNS सर्वरों के बीच इस प्रकार के क्षेत्रों को दोहराने की क्षमता है। इस अवसर का लाभ उठाने के लायक है, खासकर जब से लक्ष्य वन विंडोज सर्वर 2008 आर 2 है।

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

द्वितीयक ज़ोन का उपयोग करते समय, ज़ोन स्थानांतरण ट्रैफ़िक पहले और तीसरे तरीकों से अधिक होगा, लेकिन अनुरोध ट्रैफ़िक शून्य होगा। ज़ोन स्थानांतरण की सफलता की निगरानी के लिए एक बड़े माइनस की आवश्यकता होती है।

स्टब ज़ोन के साथ विकल्प में व्यावहारिक रूप से उसी नियम और विपक्ष हैं जो स्थानान्तरण के साथ विधि है।

तीन तरीके। कौन सा बेहतर है? अग्रेषण विधि सबसे सरल है। स्टब ज़ोन को केवल आंशिक रूप से उपयोग किया जा सकता है। दूसरी विधि अधिक जटिल है, जिसका अर्थ है कि विफलता की संभावना बढ़ जाती है। मैंने सवाल का जवाब नहीं दिया। अपने लिए निर्णय लें।
यदि इंटरैक्शन सिस्टम (क्लाइंट, DNS सर्वर) के बीच फ़ायरवॉल हैं, तो हमें DNS ट्रैफ़िक - 53 टीसीपी / यूडीपी की अनुमति देने की आवश्यकता है।
DNS सर्वर प्रबंधित करने के बारे में और जानें - http://technet.microsoft.com/en-us/library/cc794771%28WS.10%29.aspx

अब थोड़ा NETBIOS नामों को हल करने के बारे में। Windows 2000 और इसके बाद के संस्करण में नामों को हल करने का मुख्य तरीका DNS है, लेकिन ऐसे अनुप्रयोग हैं जो अभी भी NETBIOS फ़ंक्शन और लघु नामों का उपयोग करते हैं। इससे छुटकारा पाने के लिए Microsoft ने एक निश्चित कदम उठाया है। अब, Vista / Win2008 के साथ शुरू, NETBIOS फ़ंक्शन समर्थित नहीं हैं। मुझे उम्मीद है कि जल्द ही हमें NETBIOS नामों से हमेशा के लिए छुटकारा मिल जाएगा। लेकिन समर्थन की कमी का मतलब यह नहीं है कि ऐसे एप्लिकेशन विंडोज 2008 आर 2 के जंगलों में काम नहीं करेंगे। NETBIOS नामों का उपयोग भी जारी है।
NETBIOS नामों को हल करने के तीन तरीके हैं: LMHOSTS फाइलें, प्रसारण और WINS सर्वर।

LMHOSTS के लिए आपको कुछ भी स्थानांतरित करने की आवश्यकता नहीं है, ऐसी फाइलें कंप्यूटर के साथ माइग्रेट की जाती हैं। एक और बात यह है कि यदि आप माइग्रेशन प्रक्रिया के दौरान सिस्टम का नाम बदल देंगे। इस मामले में, आपको इन फ़ाइलों को मैन्युअल रूप से सही करने की आवश्यकता है। हम प्रसारण को प्रभावित नहीं कर पाएंगे, इसलिए यहां कुछ भी नहीं किया जा सकता है। WINS अवसंरचना को स्थानांतरित करने के लिए, हम निम्न विधियों में से एक का उपयोग कर सकते हैं:

1. सक्रिय निर्देशिका संसाधनों को माइग्रेट करने के बाद WinS अवसंरचना माइग्रेट करें:
   
2. नए और पुराने WINS सर्वर के बीच प्रतिकृति कॉन्फ़िगर करें, AD संसाधनों को माइग्रेट करने से पहले कंप्यूटर को नए इन्फ्रास्ट्रक्चर में स्विच करें:
   
3. दूसरी विधि की तरह, लेकिन हम एक नए जंगल में प्रवास के बाद कंप्यूटर स्विच करते हैं:
   

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

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

हमारे पास DNS को WINS के साथ एकीकृत करने का अवसर है - DNS ज़ोन के लिए एक WinS लुकअप बनाने का। क्या प्रवास के लिए ऐसा करना आवश्यक है? इसके लायक बेहतर नहीं है। यह एक अतिरिक्त जटिलता है जो त्रुटियों से भरा है और जटिल प्रणालियों की विफलता की संभावना अभी भी साधारण लोगों की तुलना में अधिक है। यदि हम वास्तविक समस्याओं के बारे में बात करते हैं, तो केर्बरोस प्रोटोकॉल का उपयोग करके प्रमाणीकरण के दौरान त्रुटियां हो सकती हैं। और यहाँ क्यों है। उदाहरण के लिए, एक उपयोगकर्ता शॉर्ट नाम SERVICE01 का उपयोग करके किसी सेवा का अनुरोध करता है। एक निश्चित प्रत्यय प्रतिस्थापित किया जाता है और नाम लंबा होता है - SERVICE01.target.com। इसके बाद, अनुरोध DNS सर्वर को भेजा जाता है, जिसमें target.com ज़ोन के लिए WINS में अवलोकन कॉन्फ़िगर किया गया है। अगर DNS को target.com ज़ोन में निर्दिष्ट रिकॉर्ड नहीं मिलता है, तो यह डोमेन लेबल को छोड़ देगा और WIN01 को SERVICE01 रिकॉर्ड के लिए कहेगा। विन एक आईपी पते के साथ जवाब देंगे। लेकिन यह प्रविष्टि किस डोमेन से है? WINS एक फ्लैट नाम प्रणाली है, इसलिए यह अज्ञात है। DNS सर्वर उपयोगकर्ता को एक प्रतिक्रिया लौटाएगा: SERVICE01.target.com = IP पता। आईपी ​​पता सबसे अधिक सही होगा - आप पिंग को जाने दे सकते हैं। लेकिन यहाँ क्या है अगर एक उपयोगकर्ता पुराने जंगल से एक सेवा का उपयोग करना चाहता था - service01.source.com। यह वह जगह है जहाँ ServicePrincipalName द्वारा सेवा की खोज करने पर समस्याएं उत्पन्न हो सकती हैं। परिणामस्वरूप, Kerberos प्रमाणीकरण समस्याएँ हो सकती हैं।

बेशक, यह समस्या प्रकट नहीं हो सकती है। यह सब अनुप्रयोगों के कार्यान्वयन और ऑपरेटिंग सिस्टम पर निर्भर करता है। लेकिन अग्रिम में ऐसी त्रुटियों की उपस्थिति को रोकना बेहतर है, खासकर जब से ऐसी त्रुटियों की श्रेणी को स्थानीय बनाना मुश्किल है।

यदि हम इन्फ्रास्ट्रक्चर के बीच WINS डेटाबेस प्रतिकृति को कॉन्फ़िगर करने का निर्णय लेते हैं तो हमें क्या करना चाहिए? क्या डेटाबेस को केवल निकटतम WINS सर्वरों के बीच दोहराया जाएगा या इसे मिश्रित प्रतिकृति बनाया जाएगा?

अपने वर्तमान प्रतिकृति मॉडल को देखें और वही करें। यदि आपके पास एक बहु-डोमेन वातावरण है और विभिन्न डोमेन से सर्वर के बीच प्रतिकृति कॉन्फ़िगर किया गया है, तो आपको NETBIOS नामों को डुप्लिकेट करने में कोई समस्या नहीं है। यदि वहाँ है, तो यह विचार करने योग्य है कि क्या एकल-डोमेन संरचना में स्थानांतरित होने पर समस्याएं होंगी। इस विन्यास में, रीढ़ की हड्डी के माध्यम से प्रतिकृति का उपयोग किया जा सकता है।

यदि प्रतिकृति का उपयोग केवल डोमेन के अंदर किया जाता है, तो भौतिक साइट के भीतर प्रतिकृति को कॉन्फ़िगर करें - पुराने डोमेन के सर्वर और नए डोमेन के समान साइट के सर्वर के बीच।

WINS सर्वर द्वारा उपयोग किए जाने वाले TCP / IP पोर्ट को खोलने के लिए आवश्यकताएँ http://technet.microsoft.com/en-us/library/cc784026%28WS.10%29.aspx हैं ।
एक जीत सर्वर के प्रबंधन के बारे में अधिक जानें - http://technet.microsoft.com/en-us/library/cc739183%28WS.10%29.aspx ।
नाम संकल्प पर विशेष ध्यान दिया जाना चाहिए। इसके अलावा, न केवल प्रवास के दौरान। नाम समाधान से संबंधित त्रुटियां कुल संख्या का 80-90% है (यदि आप आईटी विशेषज्ञों की गलतियों को ध्यान में नहीं रखते हैं)।
नाम समाधान सेटिंग वहाँ समाप्त नहीं होती है। हम इस विषय पर चर्चा करना जारी रखेंगे।

अगले लेख में, हम अपनी बुनियादी सुविधाओं के एकीकरण को जारी रखेंगे।