सोर्स और डेस्टिनेशन एनवायरमेंट, दोनों के अपने-अपने टास्क होते हैं. Google Workspace डोमेन ट्रांसफ़र को अनुमति देने से पहले, आपको ये टास्क पूरे करने होंगे.
हर ड्राई रन के बाद, डोमेन ट्रांसफ़र करने वाली टीम नतीजे देती है. इसमें यह बताया जाता है कि ट्रांसफ़र से पहले कौनसे टास्क पूरे नहीं हुए हैं और उन्हें कैसे पूरा किया जा सकता है.
ट्रांसफ़र करने से पहले, ये टास्क पूरे करें
पहला चरण: सोर्स टास्क
-
लाइसेंस अपग्रेड करें (अगर लागू हो)—ट्रांसफ़र की प्रोसेस के दौरान लाइसेंस ट्रांसफ़र नहीं किए जाते. अगर सोर्स एनवायरमेंट में, डेस्टिनेशन एनवायरमेंट से अलग Google Workspace वर्शन का इस्तेमाल किया जा रहा है, तो आपको सोर्स एनवायरमेंट को डेस्टिनेशन एनवायरमेंट के वर्शन के हिसाब से अपग्रेड करना होगा. ज़्यादा जानकारी के लिए, डेस्टिनेशन के टास्क में जाकर, लाइसेंस ट्रांसफ़र करने के बारे में पढ़ें.
ध्यान दें:
- लागत से बचने के लिए, सोर्स एनवायरमेंट में ग्रेस या ट्रायल लाइसेंस का इस्तेमाल किया जा सकता है. इससे आपको लाइसेंस को कुछ समय के लिए खरीदने की ज़रूरत नहीं पड़ेगी. हालांकि, इन बातों का ध्यान रखें:
- इन लाइसेंस की वजह से, किसी दूसरे डोमेन को प्राइमरी डोमेन के तौर पर इस्तेमाल नहीं किया जा सकता. अस्थायी लाइसेंस देने से पहले, प्राइमरी डोमेन बदलें.
- अगर डेस्टिनेशन एनवायरमेंट में उपलब्ध लाइसेंस, पूरे लाइसेंस हैं, तो ट्रांसफ़र के बाद उपयोगकर्ताओं को पूरे लाइसेंस असाइन किए जाते हैं.
- सोर्स एनवायरमेंट में मौजूद जिन उपयोगकर्ताओं को लाइसेंस असाइन नहीं किए गए हैं उन्हें भी ट्रांसफ़र किया जाता है.
- लागत से बचने के लिए, सोर्स एनवायरमेंट में ग्रेस या ट्रायल लाइसेंस का इस्तेमाल किया जा सकता है. इससे आपको लाइसेंस को कुछ समय के लिए खरीदने की ज़रूरत नहीं पड़ेगी. हालांकि, इन बातों का ध्यान रखें:
- उन लाइसेंस की सदस्यताएं रद्द करें जिनके लिए सहायता उपलब्ध नहीं है—लाइसेंस की सदस्यताएं रद्द करने से कुछ असर पड़ सकता है. Google Voice का इस्तेमाल करने वाले सोर्स एनवायरमेंट को इस चरण पर ज़्यादा ध्यान देना चाहिए. ज़्यादा जानकारी के लिए, सोर्स के लाइसेंस पर जाएं.
- Google Workspace में प्लेसहोल्डर डोमेन जोड़ें (अगर लागू हो)—सोर्स एनवायरमेंट में एक नया सेकंडरी डोमेन नेम जोड़ें और उसकी पुष्टि करें. यह डोमेन नेम, आखिर में मौजूदा प्राइमरी डोमेन की जगह लेगा. अगर कोई सेकंडरी डोमेन मौजूद है और उसे ट्रांसफ़र करने की ज़रूरत नहीं है, तो उसका इस्तेमाल किया जा सकता है. ज़्यादा जानकारी के लिए, उपयोगकर्ता के अन्य डोमेन नाम या सेकंडरी डोमेन को जोड़ना लेख पढ़ें.
- एक प्लेसहोल्डर एडमिन बनाएं और उसे खाते का मुख्य एडमिन बनाएं—प्लेसहोल्डर डोमेन से जुड़ा एक उपयोगकर्ता खाता बनाएं. अगर किसी पुराने खाते का इस्तेमाल किया जा रहा है, तो पक्का करें कि उस खाते से कोई अन्य ट्रांसफ़र डोमेन अटैच न हो. इस उपयोगकर्ता को सुपर एडमिन की भूमिका असाइन करें और उसे खाते का मुख्य एडमिन बनाएं. ज़्यादा जानकारी के लिए, बिलिंग और खाते से जुड़ी सूचनाएं किसी दूसरे एडमिन को भेजना लेख पढ़ें. पक्का करें कि Google खाते के लिए दो चरणों में पुष्टि करने की सुविधा सेट अप हो. साथ ही, प्लेसहोल्डर एडमिन खाते से कम से कम एक बार साइन इन करें, ताकि ऐक्सेस की पुष्टि की जा सके.
- प्राइमरी डोमेन को प्लेसहोल्डर डोमेन से स्वैप करें—डोमेन स्वैप करें और प्लेसहोल्डर डोमेन को नए प्राइमरी डोमेन के तौर पर प्रमोट करें.
डोमेन बदलने से पहले:
जब आप स्वैप करने के लिए तैयार हों, तब Google Workspace के लिए अपना प्राइमरी डोमेन बदलना लेख पर जाएं.
- डिवाइस की सभी सदस्यताओं को रद्द करें. इनमें Google Meet हार्डवेयर और Chrome Enterprise की सदस्यताएं शामिल हैं.
- ट्रांसफ़र करने से पहले, आपको ऐसे लाइसेंस हटाने पड़ सकते हैं जिनका इस्तेमाल नहीं किया जा सकता. ज़्यादा जानकारी के लिए, सोर्स के लाइसेंस पर जाएं.
- अगर सोर्स एनवायरमेंट में आज़माने के लिए लाइसेंस उपलब्ध हैं, तो स्वैप नहीं किया जा सकेगा. पक्का करें कि अस्थायी लाइसेंस उपलब्ध कराने से पहले ही स्वैप हो जाए.
- प्राइमरी डोमेन बदलने और सेकंडरी डोमेन इस्तेमाल करने से जुड़ी समस्याएं हो सकती हैं. प्राइमरी डोमेन बदलने के अन्य विकल्प देखें.
- मुख्य डोमेन का नाम बदलने के बाद, उपयोगकर्ताओं को ट्रांसफ़र करने या ग्रुप का नाम न बदलें. उपयोगकर्ताओं और ग्रुप को उनके ट्रांसफ़र किए गए डोमेन पर ही रखा जाना चाहिए.
- अगर आपने तीसरे पक्ष के आइडेंटिटी प्रोवाइडर का इस्तेमाल करके एसएसओ सेट अप किया है और डोमेन के हिसाब से जारी करने वाले का इस्तेमाल किया जा रहा है, तो SAML असर्शन में बदलाव करके नया प्राइमरी डोमेन दिखाया जाता है. अपने आइडेंटिटी प्रोवाइडर के कॉन्फ़िगरेशन की जांच करें, ताकि यह पक्का किया जा सके कि प्राइमरी डोमेन बदलने के बाद, उपयोगकर्ता पुष्टि कर सकें. ज़्यादा जानकारी के लिए, एसएसओ असर्शन की ज़रूरी शर्तें लेख पढ़ें.
-
Google Vault में निजी डेटा के रखरखाव के नियम लागू करना—अनिश्चित समय के लिए निजी डेटा के रखरखाव के कस्टम नियम सेट अप करें.
इन ऐप्लिकेशन के लिए एक नियम बनाएं:
- Gmail—संगठन की इकाई के लिए, रूट संगठन की इकाई चुनें.
- Google Groups—Groups के लिए, सभी ग्रुप चुनें.
इन ऐप्लिकेशन के लिए दो नियम बनाएं:
- चैट करें—संगठन की इकाई चुनें
संगठन में सबसे ऊंचे लेवल की इकाई. दूसरे नियम के लिए, सभी चैट स्पेस चुनें. - Drive—संगठन की इकाई चुनें
संगठन की मूल इकाई. दूसरे नियम के लिए, शेयर की गई सभी ड्राइव चुनें.
- Meet—संगठन की इकाई चुनें
रूट संगठन की इकाई चुनें और शेयर की गई ड्राइव से आइटम शामिल करें को चालू करें. दूसरे नियम के लिए, शेयर की गई सभी ड्राइव चुनें.
- साइटें—संगठन की इकाई चुनें
रूट संगठन की इकाई चुनें और शेयर की गई ड्राइव से आइटम शामिल करें को चालू करें. दूसरे नियम के लिए, शेयर की गई सभी ड्राइव चुनें.
इसके अलावा, ट्रांसफ़र से पहले डेस्टिनेशन एनवायरमेंट में, अनिश्चित समय के लिए निजी डेटा के रखरखाव के कस्टम नियम सेट अप किए जाते हैं. ज़्यादा जानकारी के लिए, डेस्टिनेशन एनवायरमेंट में Google Vault में डेटा को अनिश्चित काल तक सेव रखना लेख पढ़ें. Vault से डेटा ट्रांसफ़र करने के बारे में ज़्यादा जानने के लिए, डोमेन ट्रांसफ़र के साथ Vault का डेटा ट्रांसफ़र करना लेख पढ़ें.
-
सेंडर पॉलिसी फ़्रेमवर्क (एसपीएफ़) रिकॉर्ड अपडेट करें (अगर लागू हो)—अगर डेस्टिनेशन एनवायरमेंट, सोर्स एनवायरमेंट से अलग आउटबाउंड गेटवे का इस्तेमाल कर रहा है, तो सोर्स को अपना एसपीएफ़ रिकॉर्ड अपडेट करना चाहिए, ताकि उसमें आउटबाउंड गेटवे शामिल हो.
ध्यान दें: अगर DomainKeys Identified Mail (DKIM) का इस्तेमाल किया जा रहा है, तो ट्रांसफ़र से डोमेन के हिसाब से मैसेज की पुष्टि, शिकायत, और नियमों का पालन (डीएमएआरसी) करने की नीति पर कोई असर नहीं पड़ना चाहिए. ट्रांसफ़र के बाद भी SPF रिकॉर्ड अलाइन होता रहेगा. भले ही, DKIM कुछ समय के लिए अलाइन न हो. साथ ही, पक्का करें कि आपने डेस्टिनेशन एनवायरमेंट में ट्रांसफ़र के बाद डीकेआईएम से जुड़ा टास्क पूरा कर लिया हो.
- कैलेंडर के संसाधन से जुड़ी समस्याओं को ठीक करना—अगर कैलेंडर के संसाधन से जुड़ी कोई समस्या है, तो आगे बढ़ने से पहले उसे ठीक करें:
- बिल्डिंग आईडी—सोर्स एनवायरमेंट में मौजूद बिल्डिंग आईडी, डेस्टिनेशन एनवायरमेंट में मौजूद बिल्डिंग आईडी से अलग होना चाहिए. ट्रांसफ़र पर लगी रोक को हटाने के लिए, आपके पास दो विकल्प हैं. सोर्स एनवायरमेंट में जाकर, बिल्डिंग को मिटाया जा सकता है. इसके अलावा, सोर्स और डेस्टिनेशन बिल्डिंग को मर्ज करने के लिए, दोनों बिल्डिंग की जानकारी एक जैसी बनाई जा सकती है. दोनों बिल्डिंग को एक जैसा दिखाने के लिए, दोनों के आईडी, नाम, पते के सभी फ़ील्ड, जानकारी, और फ़्लोर की संख्या एक जैसी रखें.
- बिल्डिंग के नाम—अगर सोर्स एनवायरमेंट में मौजूद किसी बिल्डिंग रिसॉर्स का नाम, डेस्टिनेशन एनवायरमेंट में मौजूद किसी बिल्डिंग रिसॉर्स के नाम से मेल खाता है, तो आपको किसी एक रिसॉर्स का नाम बदलना होगा, ताकि यह समस्या ठीक हो सके. ट्रांसफ़र की प्रोसेस पूरी होने के बाद, दोनों बिल्डिंग संसाधनों को मर्ज किया जा सकता है.
- संसाधन आईडी—अगर सोर्स एनवायरमेंट में मौजूद किसी संसाधन का संसाधन आईडी, डेस्टिनेशन एनवायरमेंट में मौजूद किसी संसाधन के संसाधन आईडी से मेल खाता है, तो इससे एक ऐसी समस्या पैदा होती है जिसे ट्रांसफ़र की प्रोसेस से ठीक नहीं किया जा सकता. साथ ही, संसाधन ट्रांसफ़र नहीं होगा. टकराने वाले किसी एक संसाधन को मिटाएं और उसे ऐसे आईडी के साथ फिर से बनाएं जो टकराता न हो. मिटाए गए संसाधन को सिस्टम से पूरी तरह से हटाने में 30 दिन लगते हैं. संसाधन के पूरी तरह से मिटने का इंतज़ार करें. इसके अलावा, डोमेन ट्रांसफ़र करने वाली टीम से इसे मैन्युअल तरीके से मिटाने का अनुरोध किया जा सकता है.
- Google Cloud से जुड़े संगठन पर पड़ने वाले असर का आकलन करें (अगर लागू हो)—अगर Google Cloud का इस्तेमाल किया जा रहा है, तो उस एनवायरमेंट के एडमिन को इस बारे में सूचना दें कि Google Workspace डोमेन ट्रांसफ़र से Google Cloud पर क्या-क्या असर पड़ सकता है. अगर ज़रूरी हो, तो Google Cloud पार्टनर या Google Cloud में अपने संपर्कों से संपर्क करें. इससे आपको असर का आकलन करने और समस्या हल करने के तरीके जानने में मदद मिलेगी. डोमेन ट्रांसफ़र की प्रोसेस के दौरान, Google Workspace की डोमेन ट्रांसफ़र टीम, Google Cloud से जुड़ी सहायता नहीं देती है.
- अपने Google Workspace रीसेलर को सूचना दें (अगर लागू हो)—उन्हें डोमेन ट्रांसफ़र करने के समय के बारे में बताएं. साथ ही, उनसे अनुरोध करें कि वे ट्रांसफ़र की अवधि के दौरान खाते में कोई बदलाव न करें. उदाहरण के लिए, सदस्यताएं अपडेट न करें.
-
सोर्स या डेस्टिनेशन एनवायरमेंट में चल रहे किसी भी ऐल्फ़ा या बीटा प्रोग्राम में रजिस्टर करें (अगर लागू हो)—ऐल्फ़ा और बीटा प्रोग्राम में किए गए रजिस्ट्रेशन, सोर्स एनवायरमेंट में ट्रांसफ़र नहीं किए जाते. इसी तरह, सोर्स एनवायरमेंट, डेस्टिनेशन एनवायरमेंट में किए गए रजिस्ट्रेशन पर निर्भर कर सकता है. अगर आपको इन प्रोग्राम का इस्तेमाल जारी रखना है, तो आपको बिना रजिस्टर किए गए एनवायरमेंट के लिए आवेदन करना होगा. साथ ही, उसे इन प्रोग्राम में स्वीकार किया जाना चाहिए.
हमारा सुझाव है कि ट्रांसफ़र करने से पहले, ऐल्फ़ा या बीटा प्रोग्राम के लिए रजिस्टर करें. इससे ट्रांसफ़र करने वाले उपयोगकर्ताओं को ट्रांसफ़र की पूरी प्रोसेस के दौरान, एक जैसी सुविधाएं मिलेंगी. हालांकि, रजिस्टर करने की प्रोसेस में कुछ समय लग सकता है. साथ ही, यह भी ज़रूरी नहीं है कि आपको मंज़ूरी मिल ही जाए. इसलिए, इसका सुझाव दिया जाता है, लेकिन यह ज़रूरी नहीं है. -
Chrome डिवाइसों को ट्रांसफ़र करने के लिए, जो पहले से तैयार डिवाइसों के साथ रजिस्टर किए गए हैं:
- सोर्स एनवायरमेंट में,पहले से मौजूद प्रीप्रोविज़निंग टोकन को रद्द करें और सभी डिवाइसों को अनप्रोविज़न करें. डिवाइसों को फ़ैक्ट्री डिफ़ॉल्ट सेटिंग पर रीसेट करें.
- डेस्टिनेशन एनवायरमेंट में, पहले से प्रावधान करने का नया टोकन बनाएं.
- अनुमति पा चुके प्री-प्रोविज़निंग पार्टनर को नया टोकन दें. आपका पार्टनर, टोकन का इस्तेमाल करके डेस्टिनेशन एनवायरमेंट में डिवाइसों को पहले से सेट अप करता है.
डिवाइस इंटरनेट से कनेक्ट होने के बाद, खुद ही रजिस्टर हो जाते हैं. डिवाइस की स्थिति बदलकर 'Provisioned' हो जाती है.
पहले से तैयार डिवाइसों के बारे में ज़्यादा जानने के लिए, पहले से तैयार डिवाइस पर जाएं.
दूसरा चरण: डेस्टिनेशन टास्क
-
ट्रांसफ़र की प्रोसेस के दौरान लाइसेंस ट्रांसफ़र नहीं किए जाते. इसलिए, आपको Google Workspace के अतिरिक्त लाइसेंस उपलब्ध कराने होंगे, ताकि सभी उपयोगकर्ताओं को ट्रांसफ़र किया जा सके—उपयोगकर्ताओं को ट्रांसफ़र करने पर, उन्हें डेस्टिनेशन एनवायरमेंट में लाइसेंस का वही सेट असाइन किया जाता है जो उन्हें सोर्स एनवायरमेंट में मिला था. इसलिए, ट्रांसफ़र के समय डेस्टिनेशन एनवायरमेंट में उसी तरह के लाइसेंस उपलब्ध होने चाहिए.
अगर डेस्टिनेशन एनवायरमेंट में, सोर्स एनवायरमेंट के मुकाबले Google Workspace का कोई दूसरा वर्शन इस्तेमाल किया जा रहा है, तो पक्का करें कि लाइसेंस मैच करते हों. इसके लिए, सोर्स या डेस्टिनेशन एनवायरमेंट में लाइसेंस अपग्रेड करें.
ध्यान दें:
- Google का सुझाव है कि लाइसेंस अपग्रेड करें, ताकि सेवा बंद करने की प्रोसेस (एसडब्ल्यूपी) शुरू न हो.
- डेस्टिनेशन एनवायरमेंट में एक से ज़्यादा सदस्यताएं मौजूद हों, इसके लिए सभी ज़रूरी लाइसेंस उपलब्ध कराएं. ट्रांसफ़र के बाद, आपके पास किसी उपयोगकर्ता के लाइसेंस को अपग्रेड या डाउनग्रेड करने का विकल्प होता है. ध्यान दें कि लाइसेंस के सभी टाइप में, सीमित सुविधाओं के ऐक्सेस वाले डोमेन लाइसेंस (पीडीएल) की सुविधा काम नहीं करती.
- पक्का करें कि डेस्टिनेशन एनवायरमेंट में, ज़रूरत के मुताबिक अतिरिक्त लाइसेंस उपलब्ध हों. देखें कि डेटा ट्रांसफ़र की प्रोसेस शुरू होने और खत्म होने के बीच, हर सोर्स एनवायरमेंट में ज़्यादा उपयोगकर्ता (उदाहरण के लिए, नई भर्तियां) तो नहीं जोड़े गए हैं. अगर एक से ज़्यादा ट्रांसफ़र किए जाते हैं, तो आपको सभी ट्रांसफ़र में सोर्स उपयोगकर्ताओं की कुल संख्या का भी हिसाब रखना होगा.
- सोर्स एनवायरमेंट में मौजूद जिन उपयोगकर्ताओं को लाइसेंस असाइन नहीं किए गए हैं उन्हें भी ट्रांसफ़र किया जाता है. डेस्टिनेशन एनवायरमेंट में लाइसेंस अपने-आप असाइन होने की सुविधा पर नज़र रखें, ताकि यह पक्का किया जा सके कि इन उपयोगकर्ताओं को लाइसेंस न मिले.
- डोमेन ट्रांसफ़र के दौरान, Google Workspace के खास बिलिंग प्लान उपलब्ध नहीं होते. इसलिए, ट्रांसफ़र के दौरान अतिरिक्त लाइसेंस नहीं खरीदे जा सकते. अगर सोर्स एनवायरमेंट के लाइसेंस, सालाना बिलिंग प्लान के तहत आते हैं, तो वे चालू रहते हैं. साथ ही, आपसे सालाना प्लान के अनुबंध के खत्म होने तक शुल्क लिया जाता है. अगर आपको Google Workspace के बिलिंग प्लान के बारे में ज़्यादा जानकारी चाहिए, तो अपने बिक्री प्रतिनिधि या खाता मैनेजर से संपर्क करें.
-
पक्का करें कि एक से ज़्यादा लाइसेंस मौजूद होने पर, ट्रांसफ़र किए जा रहे उपयोगकर्ताओं पर सही लाइसेंस लागू किए गए हों—डेस्टिनेशन एनवायरमेंट में मौजूद कुछ कॉन्फ़िगरेशन से, ट्रांसफ़र किए जा रहे उपयोगकर्ताओं को लाइसेंस असाइन करने के तरीके पर असर पड़ सकता है.इस वजह से, ट्रांसफ़र किए जा रहे उपयोगकर्ताओं को उम्मीद के मुताबिक लाइसेंस नहीं मिल सकता. इन कॉन्फ़िगरेशन में, अपने-आप लाइसेंस असाइन होने की सुविधा और चुनिंदा संगठनों के लिए, अपने-आप लाइसेंस असाइन होने की सुविधा को बंद करना शामिल है.
यह पक्का करने के लिए कि ट्रांसफ़र के दौरान लाइसेंसिंग में कोई अनचाहा बदलाव न हो, आपको ये कार्रवाइयां करनी होंगी:
- अगर डेस्टिनेशन एनवायरमेंट के लिए, अपने-आप लाइसेंस असाइन होने की सुविधा का कॉन्फ़िगरेशन "सभी के लिए बंद है" पर सेट है या डेस्टिनेशन एनवायरमेंट में सिर्फ़ एक तरह का लाइसेंस है, तो कोई बदलाव करने की ज़रूरत नहीं है.
- अगर डेस्टिनेशन एनवायरमेंट के लिए, अपने-आप लाइसेंस असाइन होने की सुविधा "सभी के लिए चालू है" पर सेट है (उदाहरण के लिए, Google Workspace लाइसेंस), तो पक्का करें कि संगठन की चुनिंदा इकाइयों के लिए, लाइसेंस असाइन करने की डिफ़ॉल्ट सेटिंग को बदलने की सुविधा चालू हो. ट्रांसफ़र होने वाली, संगठन की मूल इकाई के लिए, पक्का करें कि अपने-आप लाइसेंस मिलने की सेटिंग बंद हो. साथ ही, संगठन की उप-इकाइयों के लिए, कोई अन्य सेटिंग लागू न हो.
-
ट्रांसफ़र होने वाली, संगठन की मूल इकाई बनाएं. इसके अलावा, चाहें तो सोर्स एनवायरमेंट के संगठन की इकाई का स्ट्रक्चर फिर से बनाएं—ट्रांसफ़र होने वाले सभी उपयोगकर्ताओं के लिए, संगठन की पैरंट इकाई के तौर पर काम करने वाली इकाई बनाएं. सेगमेंट बनाने के बाद, आपके पास दो विकल्प होते हैं:
- कुछ न करें—डोमेन ट्रांसफ़र की प्रोसेस में, संगठन की नई मूल इकाई के तहत सोर्स एनवायरमेंट से संगठन की इकाई का स्ट्रक्चर फिर से बनाया जाता है. यह चरण पूरा करने के लिए, ट्रांसफ़र का विकल्प "संगठन की इकाई के स्ट्रक्चर को पहले से फिर से बनाएं" को 'नहीं' पर सेट करें. ट्रांसफ़र किए जाने वाले सभी उपयोगकर्ता, संगठन की इकाई के लेवल पर लागू की गई नीतियों का पालन करते हैं.
- ट्रांसफ़र होने वाली, संगठन की मूल इकाई के तहत, सोर्स एनवायरमेंट की संगठन इकाई के स्ट्रक्चर को मैन्युअल तरीके से फिर से बनाएं—डोमेन ट्रांसफ़र से यह पक्का किया जाता है कि ट्रांसफ़र की प्रोसेस शुरू करने से पहले, सोर्स एनवायरमेंट की संगठन इकाई के पूरे स्ट्रक्चर को सही तरीके से कॉपी कर लिया गया हो. यह चरण पूरा करने के लिए, ट्रांसफ़र के विकल्प "संगठन की इकाई के स्ट्रक्चर को पहले से फिर से बनाएं" को 'हां' पर सेट करें. अगर आपको संगठन की अलग-अलग उप इकाइयों के लिए अलग-अलग नीतियां सेट करनी हैं, तो यह विकल्प आपके काम का है.
ध्यान दें: डोमेन ट्रांसफ़र से सिर्फ़ संगठन की इकाई के स्ट्रक्चर की पुष्टि होती है. यह पक्का करना आपकी ज़िम्मेदारी है कि संगठन की इकाइयों के लिए सही नीतियां सेट की गई हों.
-
सोर्स और डेस्टिनेशन एनवायरमेंट की ज़रूरी शर्तों को पूरा करने के लिए, सही नीतियां और सेटिंग तय करें—सोर्स एनवायरमेंट की नीतियां और सेटिंग, डेस्टिनेशन एनवायरमेंट में ट्रांसफ़र नहीं होती हैं. इसके अलावा, ट्रांसफर की प्रोसेस पूरी होने के बाद, डेस्टिनेशन एनवायरमेंट में मौजूद नीतियां और सेटिंग ही, ट्रांसफर किए गए उपयोगकर्ताओं और उनके डेटा पर लागू होती हैं.
आपको डेस्टिनेशन एनवायरमेंट में अपनी नीतियों और सेटिंग की समीक्षा करनी होगी. साथ ही, उनकी तुलना सोर्स एनवायरमेंट से करनी होगी. इस कार्रवाई में, ट्रांसफ़र की जाने वाली रूट संगठनात्मक इकाई के लिए सामान्य और खास सेटिंग, दोनों शामिल हैं. इससे यह पक्का किया जा सकता है कि ये सेटिंग, ट्रांसफ़र की जाने वाली सभी इकाइयों और उपयोगकर्ताओं पर लागू हों.
यहां उन नीतियों और सेटिंग की सूची दी गई है जिनकी आपको सेटअप प्रोसेस के दौरान पुष्टि करनी चाहिए. यह सूची पूरी नहीं है. साथ ही, दोनों एनवायरमेंट का पूरा ऑडिट करें, ताकि यह पक्का किया जा सके कि सभी ज़रूरी सेक्शन का विश्लेषण किया गया है:
- सेवा चालू करना (चालू/बंद)—पुष्टि करें कि सोर्स एनवायरमेंट में इस्तेमाल की जाने वाली सेवाएं, डेस्टिनेशन एनवायरमेंट में चालू हों. साथ ही, ट्रांसफ़र रूट वाली संगठन इकाई उम्मीद के मुताबिक काम कर रही हो. Google Vault का इस्तेमाल करते समय ऐसा करना खास तौर पर ज़रूरी होता है, क्योंकि सेवा बंद होने पर Vault के नियम लागू नहीं हो सकते.
- Gmail, ऐडवांस सेटिंग, और MX रिकॉर्ड—मेल रूटिंग, नियमों का पालन, और IMAP चालू करने और मेल सौंपने जैसी सेटिंग की समीक्षा करें. ज़्यादा जानकारी के लिए, Google Workspace के साथ Gmail चालू करना लेख पढ़ें.
- पासवर्ड मैनेजमेंट—अपनी पासवर्ड नीतियों की समीक्षा करें, ताकि यह पक्का किया जा सके कि वे आपके संगठन की प्रक्रियाओं के मुताबिक हैं. ट्रांसफ़र किए गए उपयोगकर्ताओं को डेस्टिनेशन एनवायरमेंट में ले जाने के बाद, उन पर डेस्टिनेशन एनवायरमेंट में लागू होने वाली पासवर्ड मैनेजमेंट की नीतियां लागू होती हैं.
- दो चरणों में पुष्टि करने की सुविधा—इससे यह कंट्रोल किया जाता है कि उपयोगकर्ताओं को अपने खाते में दो चरणों में पुष्टि करने की सुविधा जोड़ने की अनुमति है या नहीं. साथ ही, यह भी कंट्रोल किया जाता है कि यह सुविधा चालू करने की अनुमति है या इसे लागू किया गया है. अगर दो चरणों में पुष्टि करने की सुविधा चालू करने वाले उपयोगकर्ताओं को ऐसे डेस्टिनेशन एनवायरमेंट या संगठन की इकाई में ट्रांसफ़र किया जाता है जहां यह सुविधा बंद है, तो डेस्टिनेशन एडमिन उन्हें मैनेज नहीं कर पाएंगे. इसके बजाय, एडमिन इन उपयोगकर्ताओं को किसी दूसरी ओयू में ले जा सकते हैं. इससे वे दो चरणों में पुष्टि करने की सुविधा चालू करके बदलाव कर पाएंगे. इसके अलावा, वे ट्रांसफ़र करने से पहले खातों से दो चरणों में पुष्टि करने की सुविधा हटा सकते हैं.
- शेयर करने की सेटिंग—इससे यह कंट्रोल किया जाता है कि उपयोगकर्ता, संगठन से बाहर अपना कॉन्टेंट शेयर कर सकते हैं या नहीं. अगर सोर्स एनवायरमेंट में शेयर करने की सुविधा बंद है और डेस्टिनेशन एनवायरमेंट में यह सुविधा चालू है, तो ट्रांसफ़र किया गया कॉन्टेंट आपके संगठन के बाहर के लोग भी ऐक्सेस कर सकते हैं. अगर सोर्स एनवायरमेंट में डिफ़ॉल्ट रूप से शेयर करने की सुविधा चालू है और डेस्टिनेशन एनवायरमेंट में यह सुविधा चालू नहीं है, तो हो सकता है कि आपके संगठन के उपयोगकर्ता, ट्रांसफ़र किए गए कॉन्टेंट को ऐक्सेस न कर पाएं. Google Drive और Google Calendar के लिए, शेयर करने के विकल्पों के बारे में ज़्यादा जानें.
- डेटा लीक होने की रोकथाम (डीएलपी) के नियम—ये नियम, उपयोगकर्ताओं की गतिविधियों पर नज़र रखते हैं. साथ ही, उन्हें आपके संगठन से बाहर संवेदनशील जानकारी शेयर करने से रोकते हैं. जब डीएलपी, उपयोगकर्ताओं को सोर्स एनवायरमेंट में जानकारी शेयर करने से रोकता है और कॉन्टेंट को डीएलपी सेटअप किए बिना डेस्टिनेशन एनवायरमेंट में ट्रांसफ़र किया जाता है, तो डेस्टिनेशन एनवायरमेंट में मौजूद उपयोगकर्ता, आपके संगठन से बाहर जानकारी शेयर कर सकते हैं. Gmail के लिए डीएलपी के नियमों और Drive के लिए डीएलपी के नियमों के बारे में ज़्यादा जानें.
- चैट का इतिहास—इससे यह कंट्रोल किया जाता है कि चैट का इतिहास चालू है या बंद है. साथ ही, इससे यह भी कंट्रोल किया जाता है कि उपयोगकर्ता सभी चैट के लिए नीति लागू करने की सुविधा चालू कर सकते हैं या इसे डिफ़ॉल्ट के तौर पर सेट कर सकते हैं. अगर सोर्स एनवायरमेंट में चैट के इतिहास को चालू करने की अनुमति है, लेकिन डेस्टिनेशन एनवायरमेंट में इसे बंद करना ज़रूरी है, तो चैट का इतिहास मिट जाता है. Google Chat को ट्रांसफ़र नहीं किया जा सकता. हालांकि, डायरेक्ट मैसेज (डीएम) ट्रांसफ़र किए जा सकेंगे.
- डेटा क्षेत्र—इससे यह कंट्रोल किया जाता है कि माइग्रेट किए गए डेटा को किस भौगोलिक जगह पर सेव करना है. जिन उपयोगकर्ताओं को किसी खास भौगोलिक जगह पर रहना है उन्हें ट्रांसफ़र करने के लिए, डेस्टिनेशन एनवायरमेंट में इस नीति को सही तरीके से सेट किया जाना चाहिए. इससे यह पक्का किया जा सकेगा कि उनका डेटा, ज़रूरी डेटा देश/इलाके से अचानक न हट जाए. ज़्यादा जानकारी के लिए, डेटा क्षेत्र: अपने डेटा को सेव करने के लिए भौगोलिक जगह चुनना लेख पढ़ें.
- कम सुरक्षित ऐप्लिकेशन (इन्हें ऐप्लिकेशन पासवर्ड भी कहा जाता है)—अगर सोर्स एनवायरमेंट में कम सुरक्षित ऐप्लिकेशन चालू हैं और डेस्टिनेशन एनवायरमेंट में बंद हैं, तो कम सुरक्षित ऐप्लिकेशन का इस्तेमाल करने वाले ऐप्लिकेशन से कनेक्शन का टाइम आउट हो जाएगा और वह बंद हो जाएगा. टाइम आउट की अवधि, ऐप्लिकेशन के हिसाब से अलग-अलग होती है. हालांकि, आम तौर पर यह 60 मिनट के अंदर खत्म हो जाती है. असुरक्षित ऐप्लिकेशन से किए जाने वाले ऐक्सेस के अनुरोधों को ब्लॉक कर दिया जाता है. ज़्यादा जानकारी के लिए, कम सुरक्षित ऐप्लिकेशन का ऐक्सेस कंट्रोल करना लेख पढ़ें.
- OAuth स्कोप, SAML के लिए सिंगल साइन-ऑन (एसएसओ), भरोसेमंद ऐप्लिकेशन, और Chrome एक्सटेंशन—OAuth कंट्रोल से यह तय होता है कि उपयोगकर्ताओं और तीसरे पक्ष के ऐप्लिकेशन को किस लेवल का एपीआई ऐक्सेस दिया जाएगा. एसएएमएल के लिए एसएसओ (SSO) की सुविधा, Google Workspace से मिलती है. इसे कस्टम ऐप्लिकेशन के तौर पर भी लागू किया जा सकता है. इससे उपयोगकर्ता, अपने Google Workspace क्रेडेंशियल का इस्तेमाल करके अन्य ऐप्लिकेशन या सेवाओं को ऐक्सेस कर सकते हैं. भरोसेमंद ऐप्लिकेशन यह तय करते हैं कि उपयोगकर्ता, Google Workspace Marketplace या Chrome Web Store से कौनसे ऐप्लिकेशन इंस्टॉल कर सकते हैं. साथ ही, यह भी तय करते हैं कि किन ऐप्लिकेशन को OAuth से जुड़ी पाबंदियों को अनदेखा करने की अनुमति है. तीसरे पक्ष और आपके डोमेन के मालिकाना हक वाले ऐप्लिकेशन, एसएएमएल एसएसओ, Google Workspace Marketplace ऐप्लिकेशन, और Chrome ऐप्लिकेशन और एक्सटेंशन को कंट्रोल करने के तरीके के बारे में ज़्यादा जानें.
- पूरे डोमेन के डेटा का ऐक्सेस दें—इससे ऐप्लिकेशन को उपयोगकर्ताओं के Google Workspace डेटा को ऐक्सेस करने की अनुमति मिलती है. क्लाइंट और स्कोप सही तरीके से काम कर रहे हैं, यह पक्का करने के लिए, ट्रांसफ़र करने से पहले डेस्टिनेशन एनवायरमेंट में डोमेन-वाइड डेलिगेशन सेट अप करें.
अहम जानकारी: नीतियों और सेटिंग को सही तरीके से लागू न करने पर, ये समस्याएं हो सकती हैं:
- आपके संगठन से बाहर के लोगों के पास गलती से आपका डेटा ऐक्सेस हो सकता है. उदाहरण के लिए, डेस्टिनेशन एनवायरमेंट में सोर्स एनवायरमेंट की तुलना में ज़्यादा ओपन सेटिंग हैं
- पहले ऐक्सेस किए जा सकने वाले डेटा का ऐक्सेस सीमित कर दिया गया हो. उदाहरण के लिए, डेस्टिनेशन एनवायरमेंट में सोर्स एनवायरमेंट की तुलना में ज़्यादा पाबंदी वाली सेटिंग लागू की गई हों
- ट्रांसफ़र किए गए डेटा को मैनेज करने वाले कानूनी समझौते स्वीकार करें—डेस्टिनेशन एनवायरमेंट में, डेटा प्रोसेसिंग अमेंडमेंट (डीपीए), मॉडल कॉन्ट्रैक्ट क्लॉज़, और हिपा बिज़नेस असोसिएट अमेंडमेंट (बीएए) की समीक्षा करें. ज़्यादा जानकारी के लिए, Google Workspace और Cloud Identity के लिए निजता से जुड़े कानून का पालन और रिकॉर्ड लेख पढ़ें.
- अगर सोर्स एनवायरमेंट में Vault का इस्तेमाल किया जाता है, तो उसे चालू करें—अगर डेस्टिनेशन एनवायरमेंट में Vault का इस्तेमाल नहीं किया जा रहा है, लेकिन सोर्स एनवायरमेंट में किया जा रहा है, तो डेस्टिनेशन एनवायरमेंट में Vault को चालू करना होगा.
- अपने Google Workspace रीसेलर को सूचना दें (अगर लागू हो)—उन्हें डोमेन ट्रांसफ़र करने के समय के बारे में बताएं. साथ ही, उनसे अनुरोध करें कि वे ट्रांसफ़र की अवधि के दौरान खाते में कोई बदलाव न करें. उदाहरण के लिए, सदस्यताएं अपडेट न करें.
-
सोर्स या डेस्टिनेशन एनवायरमेंट में चल रहे किसी भी ऐल्फ़ा या बीटा प्रोग्राम में रजिस्टर करें (अगर लागू हो)—ऐल्फ़ा और बीटा प्रोग्राम में किए गए रजिस्ट्रेशन, सोर्स एनवायरमेंट में ट्रांसफ़र नहीं किए जाते. इसी तरह, सोर्स एनवायरमेंट, डेस्टिनेशन एनवायरमेंट में किए गए रजिस्ट्रेशन पर निर्भर कर सकता है. अगर आपको इन प्रोग्राम का इस्तेमाल जारी रखना है, तो आपको बिना रजिस्टर किए गए एनवायरमेंट के लिए आवेदन करना होगा. साथ ही, उसे इन प्रोग्राम में स्वीकार किया जाना चाहिए.
हमारा सुझाव है कि ट्रांसफ़र करने से पहले, ऐल्फ़ा या बीटा प्रोग्राम के लिए रजिस्टर करें. इससे ट्रांसफ़र करने वाले उपयोगकर्ताओं को ट्रांसफ़र की पूरी प्रोसेस के दौरान, एक जैसी सुविधाएं मिलेंगी. हालांकि, रजिस्टर करने की प्रोसेस में कुछ समय लग सकता है. साथ ही, यह भी ज़रूरी नहीं है कि आपको मंज़ूरी मिल ही जाए. इसलिए, इसका सुझाव दिया जाता है, लेकिन यह ज़रूरी नहीं है.
अहम जानकारी:
- लाइसेंस डाउनग्रेड करने पर, हो सकता है कि Google Workspace की कुछ सेवाएं और सुविधाएं काम न करें. कोई भी बदलाव करने से पहले, Google Workspace के वर्शन के बीच के अंतर और अपग्रेड या डाउनग्रेड करने के असर के बारे में ध्यान से जान लें. Google Workspace के अलग-अलग वर्शन के बारे में ज़्यादा जानें.
- लाइसेंस डाउनग्रेड करने से SWP ट्रिगर हो सकता है. इससे ट्रांसफ़र में 90 दिनों तक की देरी हो सकती है.
तीसरा चरण: अन्य काम और ध्यान रखने वाली बातें
- बदलाव का मैनेजमेंट—Google Workspace डोमेन ट्रांसफ़र टीम या ट्रांसफ़र की प्रोसेस, दोनों ही ट्रांसफ़र की प्रोसेस के दौरान उपयोगकर्ताओं को ट्रांसफ़र के बारे में अपने-आप जानकारी नहीं देती हैं. हमारा सुझाव है कि सोर्स और डेस्टिनेशन एनवायरमेंट के प्रतिनिधि, उपयोगकर्ताओं को ट्रांसफ़र की प्रोसेस और इसके संभावित असर के बारे में पहले से ही बता दें.
ट्रांसफ़र के दौरान, सोर्स और डेस्टिनेशन, दोनों एनवायरमेंट में एडमिन की सभी कार्रवाइयां ब्लॉक कर दी जाती हैं. इनमें एपीआई और Google Admin console का ऐक्सेस भी शामिल है. हमारा सुझाव है कि सोर्स और डेस्टिनेशन एनवायरमेंट के प्रतिनिधि, ट्रांसफ़र शुरू होने से पहले और ट्रांसफ़र पूरा होने के बाद, सभी डोमेन सुपर एडमिन और एडमिन ऐक्सेस वाले लोगों को इसकी सूचना दें.
- बाहरी डिपेंडेंसी—अगर Google Cloud डायरेक्ट्री सिंक (जीसीडीएस), GAM (Google Workspace एडमिन के लिए, डोमेन और उपयोगकर्ता सेटिंग मैनेज करने वाला तीसरे पक्ष का कमांड-लाइन टूल) या तीसरे पक्ष के सिंगल साइन-ऑन (एसएसओ) सेवा देने वाले किसी प्लैटफ़ॉर्म का इस्तेमाल किया जाता है, तो ट्रांसफ़र के असर का विश्लेषण ज़रूर करें. यह भी देखें कि सोर्स और डेस्टिनेशन एनवायरमेंट को एक ही एनवायरमेंट में रखने से, आपके सिस्टम और ट्रांसफ़र को पूरा होने में लगने वाले समय पर क्या असर पड़ता है.
डेस्टिनेशन एनवायरमेंट में Google Vault में निजी डेटा के रखरखाव की सुविधा, अनिश्चित समय के लिए उपलब्ध होती है
Google Workspace डोमेन ट्रांसफ़र& की सुविधा, डेस्टिनेशन एनवायरमेंट में ज़रूरत के मुताबिक अनिश्चित समय के लिए निजी डेटा के रखरखाव के नियम सेट अप करती है. डेस्टिनेशन एनवायरमेंट के एडमिन को कोई कार्रवाई करने की ज़रूरत नहीं है.
ट्रांसफ़र किए गए उपयोगकर्ताओं के लिए Vault संग्रह को ट्रांसफ़र कर दिया जाता है. हालांकि, सोर्स एनवायरमेंट के Vault के निजी डेटा के रखरखाव के नियमों को ट्रांसफ़र नहीं किया जाता है. यह पक्का करने के लिए कि ट्रांसफ़र के दौरान और बाद में, Vault का कोई भी डेटा खतरे में न पड़े, ट्रांसफ़र की प्रोसेस, ट्रांसफ़र से जुड़ी कोई भी कार्रवाई करने से पहले, डेस्टिनेशन एनवायरमेंट में निजी डेटा के रखरखाव के ये नियम बनाती है:
- Gmail—निजी डेटा के रखरखाव का कस्टम नियम (दायरा: ट्रांसफ़र होने वाली, संगठन की मूल इकाई).
- Google Calendar—निजी डेटा के रखरखाव का कस्टम नियम, जिसकी समयसीमा तय नहीं है (दायरा: ट्रांसफ़र होने वाली, संगठन की मूल इकाई).
- Google Chat—निजी डेटा के रखरखाव का कस्टम नियम, जिसकी समयसीमा तय नहीं है. (दायरा: ट्रांसफ़र रूट वाली संगठन की इकाई में ट्रांसफ़र किए गए उपयोगकर्ताओं के साथ किए गए डायरेक्ट मैसेज, लेकिन स्पेस नहीं).
- Google Drive—निजी डेटा के रखरखाव का कस्टम नियम, शेयर की गई ड्राइव शामिल नहीं हैं (दायरा: ट्रांसफ़र रूट संगठन की इकाई).
- Google Groups—निजी डेटा के रखरखाव का कस्टम नियम, जिसकी कोई समयसीमा नहीं है (दायरा: रूट संगठन की इकाई). यह डेस्टिनेशन एनवायरमेंट में मौजूद सभी ग्रुप के डेटा को सेव रखता है. इनमें वे ग्रुप भी शामिल हैं जिन्हें ट्रांसफ़र करने की प्रोसेस में शामिल नहीं किया गया है.
- Google Meet—इसके लिए, निजी डेटा के रखरखाव के दो कस्टम नियमों की ज़रूरत होती है. ये नियम अनिश्चित समय के लिए होने चाहिए:
- शेयर की गई ड्राइव शामिल नहीं हैं (स्कोप: ट्रांसफ़र होने वाली, संगठन की मूल इकाई).
- इसमें शेयर की गई सभी ड्राइव शामिल हैं (स्कोप: रूट ऑर्गनाइज़ेशनल यूनिट).
यह डेस्टिनेशन एनवायरमेंट में मौजूद सभी शेयर की गई ड्राइव का डेटा सेव करता है. इसमें वे ड्राइव भी शामिल हैं जिन्हें ट्रांसफ़र नहीं किया गया है.
- Google Sites—इसके लिए, निजी डेटा के रखरखाव के दो ऐसे कस्टम नियम ज़रूरी हैं जिनकी समयसीमा तय नहीं है.
- शेयर की गई ड्राइव शामिल नहीं हैं (स्कोप: ट्रांसफ़र होने वाली, संगठन की मूल इकाई).
- इसमें शेयर की गई सभी ड्राइव शामिल हैं (स्कोप: रूट ऑर्गनाइज़ेशनल यूनिट).
यह डेस्टिनेशन एनवायरमेंट में मौजूद सभी शेयर की गई ड्राइव का डेटा सेव करता है. इसमें वे ड्राइव भी शामिल हैं जिन्हें ट्रांसफ़र नहीं किया गया है.
- शेयर की गई ड्राइव—शेयर की गई सभी ड्राइव पर, निजी डेटा के रखरखाव का कस्टम नियम हमेशा के लिए लागू होता है. इसका दायरा, रूट संगठन की इकाई होता है. यह डेस्टिनेशन एनवायरमेंट में मौजूद सभी शेयर की गई ड्राइव का डेटा सेव करता है. इसमें वे ड्राइव भी शामिल हैं जिन्हें ट्रांसफ़र नहीं किया गया है.
अहम जानकारी: ट्रांसफ़र की प्रोसेस के दौरान, डेस्टिनेशन एनवायरमेंट में निजी डेटा के रखरखाव के नियमों को न तो हटाया जाता है और न ही उनमें बदलाव किया जाता है. ऐसा इसलिए, क्योंकि इससे डेटा हमेशा के लिए मिट सकता है.