मार्गदर्शिका

HR द्वारा प्रदान की गई CSV फ़ाइल से सैकड़ों नए उपयोगकर्ताओं को ऑनबोर्ड करें।

→Admin Console की बल्क अपलोड सुविधा का उपयोग करें। उपयोगकर्ताओं को सीधे सही OUs में रखने के लिए CSV में `Org Unit Path` कॉलम शामिल करें।

क्यों: स्क्रिप्टिंग के बिना सही नीति असाइनमेंट के साथ बड़ी संख्या में उपयोगकर्ता बनाने का सबसे कुशल तरीका। एक बार के ऑनबोर्डिंग के लिए GCDS से अधिक सीधा।

एक कर्मचारी नौकरी छोड़ रहा है। उनकी Drive फ़ाइलों को संरक्षित करें और उन्हें उनके प्रबंधक के नियंत्रण में स्थानांतरित करें।

→उपयोगकर्ता को निलंबित या हटाने से पहले, सभी Drive फ़ाइलों का स्वामित्व प्रबंधक को स्थानांतरित करने के लिए Admin Console के डेटा ट्रांसफर टूल का उपयोग करें।

क्यों: डेटा अखंडता को संरक्षित करता है और व्यावसायिक निरंतरता सुनिश्चित करता है। सीधा स्वामित्व हस्तांतरण साझा करने की तुलना में स्वच्छ है और एक स्पष्ट ऑडिट ट्रेल बनाए रखता है।

विभिन्न विभागों और टीमों को अद्वितीय सेवा सेटिंग्स और सुरक्षा नीतियों की आवश्यकता होती है।

→एक पदानुक्रमित संगठनात्मक इकाई (OU) संरचना (उदाहरण के लिए, /Sales/East, /Sales/West) बनाएं। पैरेंट OU पर व्यापक नीतियां लागू करें और चाइल्ड OUs पर विशिष्ट ओवरराइड लागू करें।

क्यों: OUs पदानुक्रमित नीति इनहेरिटेंस प्रदान करते हैं, जिससे विभिन्न उपयोगकर्ता आबादी के लिए सेटिंग्स पर स्केलेबल और दानेदार नियंत्रण संभव होता है।

नए कर्मचारियों सहित इंजीनियरिंग विभाग के सभी उपयोगकर्ताओं के लिए समूह सदस्यता को स्वचालित करें।

→उपयोगकर्ता विशेषता `department==Engineering` के आधार पर सदस्यता क्वेरी के साथ एक Dynamic Group बनाएं।

क्यों: उपयोगकर्ता विशेषताओं के आधार पर सदस्यता को स्वचालित रूप से प्रबंधित करता है, मैन्युअल अपडेट को समाप्त करता है और उपयोगकर्ता भूमिकाओं में बदलाव के साथ निरंतरता सुनिश्चित करता है।

हेल्प डेस्क कर्मचारियों को केवल मुख्य कार्यालय OU में उपयोगकर्ताओं के लिए पासवर्ड रीसेट करने की क्षमता प्रदान करें।

→केवल "Users > Reset Password" विशेषाधिकार के साथ एक कस्टम एडमिन भूमिका बनाएं। इस भूमिका को हेल्प डेस्क टीम को असाइन करें और इसे केवल लक्षित OU पर लागू होने के लिए स्कोप करें।

क्यों: न्यूनतम विशेषाधिकार के सिद्धांत को लागू करता है। कस्टम, स्कोप वाली भूमिकाएँ प्रत्यायोजित प्रशासकों को उनकी जिम्मेदारी के बाहर के उपयोगकर्ताओं या सेटिंग्स को प्रभावित करने से रोकती हैं।

GCDS के माध्यम से Active Directory से सिंक कर रहा है, लेकिन उपयोगकर्ता UPNs का एक पुराना डोमेन है। नए, सही डोमेन के साथ उपयोगकर्ता बनाने की आवश्यकता है।

→GCDS में, ईमेल पते विशेषता के लिए एक विशेषता परिवर्तन नियम कॉन्फ़िगर करें ताकि पुराने डोमेन स्ट्रिंग को नए से बदला जा सके।

क्यों: सिंक प्रक्रिया के दौरान डेटा को सही करता है, जिसके लिए स्रोत Active Directory में संशोधन की आवश्यकता नहीं होती है, जो अक्सर संभव नहीं होता है।

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

→Admin console से, हाल ही में हटाए गए उपयोगकर्ता को पुनर्स्थापित करें। रिकवरी विंडो 20 दिनों की है। एक बार पुनर्स्थापित होने के बाद, डेटा स्थानांतरित करें, फिर यदि आवश्यक हो तो फिर से हटा दें।

क्यों: हटाए गए उपयोगकर्ता 20 दिनों के लिए पुनर्प्राप्त करने योग्य हैं। यदि कोई Vault होल्ड/रिटेंशन मौजूद नहीं था तो उनके डेटा को पुनर्प्राप्त करने का यह एकमात्र तरीका है।

एक सहायता टीम को एक साझा ईमेल पते (support@) की आवश्यकता है जहाँ कई सदस्य ग्राहक पूछताछ का प्रबंधन, असाइन और ट्रैक कर सकें।

→एक Google Group बनाएं और इसे "Collaborative Inbox" के रूप में कॉन्फ़िगर करें।

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

बिक्री विभाग से सभी आउटगोइंग ईमेल पर एक मानकीकृत कानूनी अस्वीकरण और ब्रांडिंग लागू करें।

→Gmail सेटिंग्स में, एक "Append footer" कार्रवाई के साथ एक अनुपालन नियम कॉन्फ़िगर करें, जिसे Sales OU तक सीमित किया गया हो।

क्यों: यह सर्वर स्तर पर एक गैर-संपादन योग्य फुटर जोड़ता है, जिससे 100% अनुपालन सुनिश्चित होता है। उपयोगकर्ता-पक्ष समाधानों को संशोधित या बायपास किया जा सकता है।

उपयोगकर्ताओं को Drive फ़ाइलों को बाहरी रूप से साझा करने की अनुमति दें, लेकिन केवल विशिष्ट, अनुमोदित भागीदार डोमेन के साथ।

→Drive साझाकरण सेटिंग्स में, भागीदार डोमेन को "Allowlisted domains" सूची में जोड़ें और साझाकरण नीति को "Allowlisted domains only" पर सेट करें।

क्यों: सुरक्षा और सहयोग के बीच संतुलन प्रदान करता है, अनधिकृत बाहरी पार्टियों के साथ डेटा साझा करने से रोकता है जबकि अनुमोदित साझेदारियों को सक्षम करता है।

Google Meet में बाहरी मेहमानों को अनुमति दें, लेकिन उन्हें आंतरिक होस्ट के आने से पहले शामिल होने से रोकें।

→Google Meet सुरक्षा सेटिंग्स में, सुनिश्चित करें कि "होस्ट को आपके संगठन के बाहर के लोगों को स्वीकार करना होगा" (दस्तक देना) सक्षम है।

क्यों: एक वर्चुअल लॉबी बनाकर मीटिंग सुरक्षा को बढ़ाता है, जिससे होस्ट को यह नियंत्रित करने का अधिकार मिलता है कि बाहरी प्रतिभागी कब और कौन शामिल हो सकते हैं।

इनबाउंड ईमेल के लिए शून्य डाउनटाइम के साथ ऑन-प्रिमाइसेस Exchange सर्वर से Gmail में माइग्रेट करना।

→डुअल डिलीवरी कॉन्फ़िगर करें। Workspace में मेल को लेगेसी Exchange सर्वर पर फ़ॉरवर्ड करने के लिए एक मेल रूट सेट करें, फिर MX रिकॉर्ड को Google की ओर इंगित करें।

क्यों: यह सुनिश्चित करता है कि उपयोगकर्ता चरणबद्ध माइग्रेशन के दौरान दोनों मेलबॉक्स में मेल प्राप्त करें, जिससे संदेशों का नुकसान नहीं होता और सुचारु संक्रमण संभव होता है।

उपयोगकर्ताओं को Docs, Sheets और Gmail में अप्रत्याशित तृतीय-पक्ष ऐड-ऑन स्थापित करने से रोकें।

→Marketplace सेटिंग्स में, अनुमोदित अनुप्रयोगों की एक allowlist कॉन्फ़िगर करें और उपयोगकर्ताओं को केवल allowlisted ऐप्स तक सीमित करने के लिए नीति सेट करें।

क्यों: IT-अनुमोदित टूल का एक "सुरक्षित वातावरण" बनाकर दुर्भावनापूर्ण या डेटा-भूखे तृतीय-पक्ष ऐप्स से सुरक्षा जोखिम कम करता है।

अनुपालन के लिए, सभी ईमेल को 7 साल तक बनाए रखना चाहिए, भले ही उपयोगकर्ता उन्हें अपने मेलबॉक्स से हटा दें।

→Google Vault में, Gmail के लिए 7 साल की अवधि के साथ एक कस्टम रिटेंशन नियम बनाएं। कोई समाप्ति सेट न करें।

क्यों: Vault रिटेंशन उपयोगकर्ता कार्यों से स्वतंत्र रूप से संचालित होता है। यह eDiscovery और अनुपालन के लिए एक कानूनी रूप से बचाव योग्य संग्रह प्रदान करता है, जो लाइव उपयोगकर्ता मेलबॉक्स से अलग है।

कानूनी विभाग को लंबित मुकदमेबाजी के लिए विशिष्ट कर्मचारियों (कस्टोडियन) के सभी डेटा को अनिश्चित काल के लिए संरक्षित रखने की आवश्यकता है।

→Google Vault में, एक Matter बनाएं, उपयोगकर्ताओं को कस्टोडियन के रूप में पहचानें, और उन पर एक Legal Hold लगाएं।

क्यों: एक Legal Hold सभी रिटेंशन और विलोपन नीतियों को ओवरराइड करता है। डेटा तब तक संरक्षित रहता है जब तक होल्ड स्पष्ट रूप से जारी नहीं हो जाता, जिससे कानूनी संरक्षण दायित्वों को पूरा किया जा सके।

उपयोगकर्ताओं को क्रेडिट कार्ड नंबर या PII वाले दस्तावेज़ों को बाहरी पार्टियों के साथ गलती से साझा करने से रोकें।

→`Security > Data protection` में एक Data Loss Prevention (DLP) नियम बनाएं। पूर्वनिर्धारित डिटेक्टरों (जैसे, क्रेडिट कार्ड नंबर) का उपयोग करें और बाहरी साझाकरण के लिए ट्रिगर स्थिति सेट करें। कार्रवाई "Block external sharing" होनी चाहिए।

क्यों: DLP डेटा सुरक्षा नीतियों को स्वचालित रूप से लागू करने के लिए वास्तविक समय में सामग्री को स्कैन करता है, जिससे मानवीय त्रुटि के कारण डेटा उल्लंघनों का जोखिम कम होता है।

GDPR का अनुपालन करने के लिए, सुनिश्चित करें कि यूरोपीय कर्मचारियों के लिए सभी प्राथमिक डेटा यूरोपीय डेटा केंद्रों के भीतर संग्रहीत हों।

→यूरोपीय उपयोगकर्ताओं को एक समर्पित OU में रखें। `Account > Data regions` में, उस OU पर "Europe" के लिए डेटा क्षेत्र नीति लागू करें।

क्यों: यह सुविधा विशिष्ट सेवाओं के लिए प्राथमिक डेटा के भौगोलिक भंडारण स्थान को नियंत्रित करके डेटा निवास आवश्यकताओं को सीधे संबोधित करती है।

एक उपयोगकर्ता ने 10 दिन पहले एक महत्वपूर्ण Drive फ़ाइल को स्थायी रूप से हटा दिया था। यह अब उनके ट्रैश में नहीं है।

→यदि उपयोगकर्ता को कोई Vault रिटेंशन नियम या होल्ड कवर कर रहा था, तो Vault में फ़ाइल खोजें और पुनर्प्राप्ति के लिए इसे निर्यात करें।

क्यों: Vault एक सुरक्षा जाल के रूप में कार्य करता है। रिटेंशन/होल्ड द्वारा कवर किया गया डेटा उपयोगकर्ता द्वारा "स्थायी रूप से" हटा दिए जाने के बाद भी संरक्षित रहता है।

एक कर्मचारी, जिस पर कानूनी रोक लगी है, नौकरी छोड़ रहा है। आपको उनके डेटा और रोक को संरक्षित करने की आवश्यकता है, लेकिन उनके पूर्ण लाइसेंस को मुक्त करें।

→उपयोगकर्ता खाते को निलंबित करें और एक "Archived User" (AU) लाइसेंस असाइन करें। डेटा Vault में रहता है और रोक के अधीन होता है।

क्यों: AU लाइसेंस अनुपालन और कानूनी उद्देश्यों के लिए पूर्व कर्मचारियों के डेटा को संरक्षित करने का एक लागत प्रभावी तरीका है, बिना पूर्ण, सक्रिय लाइसेंस का उपभोग किए।

Workspace तक पहुँच केवल कॉर्पोरेट-प्रबंधित डिवाइस से या कार्यालय नेटवर्क से कनेक्ट होने पर ही अनुमति दें।

→Context-Aware Access कॉन्फ़िगर करें। "Compliant device" (एंडपॉइंट प्रबंधन से) और "Corporate IP range" के लिए एक्सेस स्तर बनाएं। एक नीति लागू करें जिसके लिए पहुँच के लिए इनमें से एक स्तर की आवश्यकता हो।

क्यों: यह Workspace के लिए शून्य-विश्वास मॉडल का मूल है, जो नेटवर्क परिधि से डिवाइस और उपयोगकर्ता संदर्भ के आधार पर एक्सेस नीतियों को लागू करने की ओर बढ़ रहा है, स्थान की परवाह किए बिना।

एक उपयोगकर्ता खाते पर समझौता होने का संदेह है। हमलावर के पास सक्रिय सत्र या ऐप एक्सेस हो सकता है।

→तुरंत: 1) उपयोगकर्ता का पासवर्ड रीसेट करें। 2) सभी तृतीय-पक्ष OAuth टोकन रद्द करें। 3) सभी वेब सत्रों से साइन आउट करें।

क्यों: यह तीन-चरणीय प्रक्रिया सुनिश्चित करती है कि हमलावर सभी एक्सेस बिंदुओं से बाहर हो जाए: सीधा लॉगिन, ऐप-आधारित एक्सेस और मौजूदा ब्राउज़र सत्र।

उपयोगकर्ताओं को जोखिम भरे या अप्रत्याशित तृतीय-पक्ष OAuth अनुप्रयोगों को कॉर्पोरेट डेटा एक्सेस प्रदान करने से रोकें।

→`Security > API controls` में, डिफ़ॉल्ट रूप से असंरचित ऐप्स को ब्लॉक करने के लिए "App access control" कॉन्फ़िगर करें, फिर विशिष्ट, जाँचे गए ऐप्स को "Trusted" सूची में जोड़ें।

क्यों: यह तृतीय-पक्ष ऐप्स के लिए डिफ़ॉल्ट-अनुमति से डिफ़ॉल्ट-अस्वीकार सुरक्षा स्थिति में बदलाव करता है, जिससे IT को यह नियंत्रित करने का पूरा अधिकार मिलता है कि कौन से एप्लिकेशन कंपनी डेटा तक पहुँच सकते हैं।

तृतीय-पक्ष IdP के साथ Single Sign-On (SSO) लागू करें, लेकिन यदि IdP डाउन है तो एडमिन एक्सेस सुनिश्चित करें।

→पूरे संगठन के लिए SAML SSO कॉन्फ़िगर करें। Super Admins के लिए एक अलग समूह या OU बनाएं और उन्हें SSO आवश्यकता से बाहर करने के लिए एक नेटवर्क मास्क या समूह सेटिंग कॉन्फ़िगर करें।

क्यों: एक महत्वपूर्ण "ब्रेक-ग्लास" प्रक्रिया प्रदान करता है, जिससे प्रशासकों को IdP आउटेज के दौरान Google क्रेडेंशियल के साथ लॉग इन करके पर्यावरण का प्रबंधन करने की अनुमति मिलती है।

हमलावरों को फ़िशिंग हमलों में आपके डोमेन को स्पूफ करने से रोकें और ईमेल डिलिवरेबिलिटी में सुधार करें।

→अपने डोमेन के लिए SPF, DKIM, और DMARC DNS रिकॉर्ड को ठीक से कॉन्फ़िगर करें। पूर्ण प्रवर्तन के लिए DMARC नीति को `p=reject` पर सेट करें।

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

संदिग्ध लॉगिन या सरकार-समर्थित हमले की चेतावनियों जैसे सुरक्षा घटनाओं की सक्रिय सूचना की आवश्यकता है।

→Alert Center की नियमित रूप से निगरानी करें। सुरक्षा टीम को उच्च-प्राथमिकता वाली घटनाओं के लिए ईमेल सूचनाएं भेजने के लिए अलर्ट नियम कॉन्फ़िगर करें।

क्यों: Alert Center सुरक्षा-संबंधी घटनाओं के लिए केंद्रीकृत हब है। सक्रिय सूचनाएं त्वरित घटना प्रतिक्रिया को सक्षम करती हैं।

एक उपयोगकर्ता ने अपना फोन खो दिया और उनके पास कोई बैकअप कोड नहीं है, जिससे वे अपने 2SV-संरक्षित खाते से लॉक हो गए हैं।

→एक एडमिन के रूप में, उपयोगकर्ता का चयन करें और उन्हें फिर से एक्सेस प्राप्त करने के लिए एक बार उपयोग होने वाले बैकअप सत्यापन कोड उत्पन्न करें।

क्यों: यह उपयोगकर्ता पुनर्प्राप्ति के लिए मानक, सुरक्षित प्रक्रिया है जिसके लिए 2SV को अस्थायी रूप से अक्षम करने की आवश्यकता नहीं है, जिससे सुरक्षा कमजोर हो जाएगी।

उच्च-जोखिम वाले उपयोगकर्ताओं को फ़िशिंग से बचाने के लिए प्रमाणीकरण के सबसे मजबूत रूप को अनिवार्य करें।

→एक 2-Step Verification नीति लागू करें जिसके लिए केवल Security Keys (FIDO) के उपयोग की आवश्यकता हो।

क्यों: सुरक्षा कुंजी फ़िशिंग-प्रतिरोधी होती हैं क्योंकि वे सार्वजनिक-कुंजी क्रिप्टोग्राफी का उपयोग करती हैं और लॉगिन पृष्ठ के मूल को सत्यापित करती हैं, TOTP या SMS के विपरीत जिन्हें फ़िश किया जा सकता है।

संवेदनशील डेटा वाला कंपनी-प्रबंधित मोबाइल फोन खो गया या चोरी हो गया है।

→Admin console में Devices के तहत, डिवाइस का पता लगाएं और तुरंत एक दूरस्थ "Wipe device" कमांड शुरू करें।

क्यों: यह खोए हुए प्रबंधित डिवाइस के लिए प्राथमिक सुरक्षा प्रतिक्रिया है। यह डिवाइस को दूरस्थ रूप से फ़ैक्टरी रीसेट करता है या कार्य प्रोफ़ाइल को मिटा देता है, कॉर्पोरेट डेटा को अनधिकृत पहुँच से बचाता है।

सभी कॉर्पोरेट Chrome ब्राउज़रों (Windows, Mac) पर सुरक्षा सेटिंग्स और अनिवार्य एक्सटेंशन का एक मानक सेट लागू करें।

→ब्राउज़रों को Chrome Browser Cloud Management (CBCM) में नामांकित करें। उपयोगकर्ता/ब्राउज़र OU पर नीतियां लागू करें ताकि एक्सटेंशन को जबरन स्थापित किया जा सके, दूसरों को ब्लॉक किया जा सके और सेटिंग्स कॉन्फ़िगर की जा सकें।

क्यों: CBCM किसी भी प्लेटफ़ॉर्म पर Chrome ब्राउज़रों का केंद्रीकृत, क्लाउड-आधारित प्रबंधन प्रदान करता है, जिससे सुसंगत नीति और सुरक्षा स्थिति सुनिश्चित होती है।

कर्मचारियों को काम के लिए व्यक्तिगत Android डिवाइस (BYOD) का उपयोग करने की अनुमति दें, जबकि कॉर्पोरेट डेटा को अलग और सुरक्षित रखें।

→Advanced Mobile Management लागू करें और कर्मचारी-स्वामित्व वाले डिवाइस पर एक Android Work Profile के निर्माण को लागू करें।

क्यों: एक Work Profile एक OS-स्तर का कंटेनर बनाता है जो कार्य ऐप्स और डेटा को व्यक्तिगत डेटा से अलग करता है। पूरे कंटेनर को उपयोगकर्ता की व्यक्तिगत फ़ाइलों को प्रभावित किए बिना दूरस्थ रूप से मिटाया जा सकता है।

एक Context-Aware Access नीति को यह सत्यापित करना होगा कि डिवाइस कंपनी के स्वामित्व में है और एक्सेस प्रदान करने से पहले एन्क्रिप्टेड है।

→सभी प्रबंधित डिवाइसों पर Google Endpoint Verification एक्सटेंशन/एजेंट को तैनात करें। CAA एक्सेस स्तर को "Compliant" या "Company-owned" डिवाइस स्थिति की आवश्यकता के लिए कॉन्फ़िगर करें।

क्यों: Endpoint Verification वह एजेंट है जो CAA इंजन को डिवाइस की स्थिति एकत्र और रिपोर्ट करता है, जिससे डिवाइस विश्वास-आधारित एक्सेस नियंत्रण सक्षम होता है।

उपयोगकर्ता रिपोर्ट करते हैं कि किसी विशिष्ट भागीदार को ईमेल बाउंस हो रहे हैं या गंभीर रूप से देरी हो रही है।

→Admin Console में "Email Log Search" टूल का उपयोग करें। पूर्ण डिलीवरी पथ, टाइमस्टैम्प और प्राप्तकर्ता सर्वर से किसी भी अस्वीकृति त्रुटि को देखने के लिए एक नमूना संदेश खोजें।

क्यों: Email Log Search डिलीवरी समस्याओं के निदान के लिए निश्चित उपकरण है। यह दानेदार विवरण प्रदान करता है जो पुष्टि करता है कि संदेश Google से निकला या नहीं और इसे क्यों अस्वीकार किया गया।

संगठन भर में कई उपयोगकर्ता अचानक लॉग इन करने में असमर्थ हैं, क्रेडेंशियल सत्यापन त्रुटियों की रिपोर्ट कर रहे हैं।

→समस्या संभवतः तृतीय-पक्ष Identity Provider (IdP) के साथ है। IdP सेवा की स्थिति और SSO कॉन्फ़िगरेशन में SAML प्रमाणपत्र की वैधता की जांच करें।

क्यों: SSO वातावरण में व्यापक, अचानक लॉगिन विफलताएं लगभग हमेशा बाहरी IdP की ओर इशारा करती हैं, न कि व्यक्तिगत उपयोगकर्ता खातों की ओर।

एक उपयोगकर्ता रिपोर्ट करता है कि उनके Google Authenticator ऐप से 6-अंकीय कोड लगातार अस्वीकार किए जा रहे हैं।

→उपयोगकर्ता को उनके मोबाइल डिवाइस पर घड़ी की जांच और सिंक करने का निर्देश दें। Authenticator ऐप में एक समय सुधार सुविधा है।

क्यों: टाइम-आधारित OTP (TOTP) कोड अत्यधिक सिंक्रनाइज़ किए गए समय पर निर्भर करते हैं। कोड अस्वीकृति का सबसे आम कारण घड़ी का विचलन है।

एक विशिष्ट कार्यालय में उपयोगकर्ता खराब Google Meet वीडियो गुणवत्ता की शिकायत करते हैं, जबकि अन्य कार्यालय ठीक हैं।

→प्रभावित कार्यालय में स्थानीय नेटवर्क की जांच करें। बैंडविड्थ संतृप्ति, उच्च विलंबता/जिटर की जांच करें, और सुनिश्चित करें कि फ़ायरवॉल नियम Google Meet ट्रैफ़िक को थ्रॉटल या ब्लॉक नहीं कर रहे हैं।

क्यों: स्थान-विशिष्ट प्रदर्शन समस्याएं लगभग हमेशा स्थानीय नेटवर्क समस्याओं के कारण होती हैं, न कि Google सेवा के कारण।

एक उपयोगकर्ता को बाहरी प्रेषक से ईमेल प्राप्त नहीं हो रहे हैं, लेकिन उनके सहयोगियों को हो रहे हैं।

→आने वाले ईमेल को रीडायरेक्ट या हटाने वाले किसी भी फ़िल्टर या अवरुद्ध प्रेषक नियमों के लिए उपयोगकर्ता की व्यक्तिगत Gmail सेटिंग्स की जांच करें।

क्यों: जब कोई समस्या केवल एक ही उपयोगकर्ता को प्रभावित करती है, तो कारण अक्सर संगठन-स्तर की नीति के बजाय उपयोगकर्ता-स्तर का कॉन्फ़िगरेशन होता है।

एक उपयोगकर्ता Meet रिकॉर्डिंग शुरू कर सकता है, लेकिन मीटिंग समाप्त होने के बाद यह सहेजने में विफल रहता है।

→उपयोगकर्ता के Google Drive स्टोरेज कोटा की जांच करें। यदि उपयोगकर्ता के पास अपर्याप्त स्थान है तो रिकॉर्डिंग विफल हो जाती है।

क्यों: Meet रिकॉर्डिंग आयोजक के "My Drive" में "Meet Recordings" फ़ोल्डर में सहेजी जाती हैं। पूर्ण Drive कोटा सहेजने की विफलताओं का सबसे आम कारण है।