GCDS से जुड़ी सामान्य समस्याएं हल करना

Configuration Manager का इस्तेमाल करके, कॉन्फ़िगरेशन से जुड़ी समस्या हल करना

अगर आपको सिंक्रनाइज़ेशन को सही तरीके से चलाने में समस्या आ रही है, तो पुष्टि करें कि कॉन्फ़िगरेशन मैनेजर में कॉन्फ़िगरेशन की जानकारी सही है. साथ ही, यह नोट करें कि कौनसे टेस्ट पूरे नहीं हुए:

1. Configuration Manager में, वह XML फ़ाइल खोलें जिसका इस्तेमाल सिंक्रनाइज़ेशन को कॉन्फ़िगर करने के लिए किया जा रहा है.
2. LDAP कनेक्शन पेज पर, कनेक्शन की जांच करें पर क्लिक करके पुष्टि करें कि LDAP सर्वर से कनेक्ट किया जा सकता है.
3. सूचनाएं पेज पर, टेस्ट सूचना पर क्लिक करें. इससे पुष्टि होगी कि टेस्ट सूचना भेजी जा सकती है.
4. सिंक करें पेज पर, सिंक करने का सिम्युलेशन करें पर क्लिक करें. इससे यह पुष्टि की जा सकेगी कि आपने सभी ज़रूरी फ़ील्ड भर दिए हैं और सिंक्रनाइज़ेशन की प्रोसेस चल रही है.

मैं एपीआई अनुरोधों के लिए, पूरी एचटीटीपी लॉगिंग कैसे चालू करूं?

कुछ मामलों में, सहायता टीम आपसे GCDS में ट्रेस-लेवल की लॉगिंग चालू करने के साथ-साथ, पूरी एचटीटीपी लॉगिंग चालू करने के लिए भी कह सकती है. पूरी एचटीटीपी लॉगिंग का इस्तेमाल यह देखने के लिए किया जाता है कि GCDS ने कौनसे एपीआई अनुरोध किए हैं और Google के एपीआई ने क्या जवाब दिए हैं.

अहम जानकारी: पूरे एचटीटीपी लॉग में बेहद संवेदनशील जानकारी हो सकती है. सहायता टीम को लॉग भेजने से पहले, उनमें से कोई भी संवेदनशील जानकारी (जैसे कि मौजूदा refresh_token या access_token फ़ील्ड) हटा दें.

एचटीटीपी की पूरी लॉगिंग चालू करने के लिए:

1. पक्का करें कि GCDS, sync-cmd या Configuration Manager के साथ काम न कर रहा हो.
2. GCDS के इंस्टॉलेशन फ़ोल्डर पर जाएं.

3. jre/lib/logging.properties फ़ाइल में बदलाव करें.

4. फ़ाइल के आखिर में ये लाइनें जोड़ें:

   java.util.logging.FileHandler.pattern = %h/gcdshttp%u.%g.log
   java.util.logging.FileHandler.limit = 5000000
   java.util.logging.FileHandler.count = 100
   java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
   handlers = java.util.logging.FileHandler
   com.google.api.client.http.level = CONFIG
   
   com.google.gdata.client.http.HttpGDataRequest.level = ALL
   sun.net.www.protocol.http.HttpURLConnection.level = ALL

5. फ़ाइल सेव करें.
6. GCDS को फिर से सिंक करें. इसके लिए, लॉगिंग को Trace पर सेट करें.

   gcdshttp*.log नाम की लॉग फ़ाइलें, homedir (Linux) या प्रोफ़ाइल फ़ोल्डर (Microsoft Windows) में बनाई जाती हैं. इन फ़ाइलों को एक साथ संग्रहित करें, क्योंकि इनका साइज़ काफ़ी बड़ा हो सकता है.

7. चौथे चरण में जोड़ी गई लाइनों को मिटाएं, ताकि आने वाले समय में बड़ी लॉग फ़ाइलें न बन पाएं.
8. सहायता पाने के लिए, ये फ़ाइलें उपलब्ध कराएं:
   • एक्सएमएल फ़ाइल
   • ट्रेस-लेवल के लॉग और हाल ही में हुए सिंक की gcdshttp*.log फ़ाइलें

अहम जानकारी: अगर आपको किसी नई क्लास के लिए लॉगिंग की सुविधा चालू करनी है, तो class.fqdn.level = ALL के तौर पर एक लाइन जोड़ें. पूरे सेटअप ब्लॉक को डुप्लीकेट करने की ज़रूरत नहीं है.

डीबग करने वाली प्रॉक्सी का इस्तेमाल करना

अनुरोध और जवाब के मुख्य हिस्से का साइज़ 16 केबी से ज़्यादा नहीं होना चाहिए. अगर आपको कोई ऐसी लॉग एंट्री दिखती है जिसे छोटा कर दिया गया है, क्योंकि वह तय सीमा से ज़्यादा है, तो डीबग करने के लिए प्रॉक्सी का इस्तेमाल करें. जैसे, Fiddler.

Fiddler को चालू करने के लिए, यह तरीका अपनाएं:

1. उस पाथ पर जाएं जहां GCDS इंस्टॉल किया गया है. उदाहरण के लिए, C:\Program Files\Google Cloud Directory Sync.
2. सीआरएल की जांच बंद करने के लिए, .vmoptions फ़ाइलों (उदाहरण के लिए, config-manager.vmoptions या sync-cmd.vmoptions) में ये फ़्लैग जोड़ें:

   -Dcom.sun.security.enableCRLDP=false

   -Dcom.sun.net.ssl.checkRevocation=false

बदलावों को लागू करने के लिए, GCDS को रीस्टार्ट करें.

1. Google डोमेन कॉन्फ़िगरेशन की प्रॉक्सी सेटिंग में, Fiddler को प्रॉक्सी के तौर पर कॉन्फ़िगर करें. होस्टनेम फ़ील्ड में, लोकल आईपी पता 127.0.0.1 जोड़ें. डिफ़ॉल्ट पोर्ट 8888 है. हालांकि, इसकी पुष्टि करने के लिए Fiddler खोलें. इसके बाद, Options > Connections पर जाएं. इसके बाद, "Fiddler Classiclistens on port" फ़ील्ड में मौजूद वैल्यू देखें.

अगर Linux पर GCDS का इस्तेमाल किया जा रहा है, तो Windows के भरोसेमंद सर्टिफ़िकेट स्टोर का इस्तेमाल नहीं किया जा सकता. इसलिए, आपको Fiddler रूट सर्टिफ़िकेट को GCDS के Java ट्रस्ट स्टोर में इंपोर्ट करना होगा. इन चरणों के बारे में ज़्यादा जानने के लिए, सर्टिफ़िकेट से जुड़ी समस्याओं को हल करना पर जाएं.

एसएमटीपी रिले होस्ट को सेट अप करने में समस्या

अगर आपको सूचनाओं के लिए, एसएमटीपी रिले होस्ट सेट अप करने में समस्याएं आ रही हैं, तो समस्या हल करने के लिए यह तरीका अपनाएं.

कनेक्ट नहीं हो सका और एसएमटीपी होस्ट के बारे में जानकारी नहीं है

1. कोई कमांड प्रॉम्प्ट खोलें.
2. यह देखने के लिए कि एसएमटीपी सर्वर का कॉन्फ़िगर किया गया होस्टनेम, आईपी पते में बदलता है या नहीं, यह कमांड डालें:

   nslookup smtp-host-name.com

कनेक्ट नहीं किया जा सका और SMTP होस्ट से कनेक्ट नहीं किया जा सका मैसेज

देखें कि GCDS चलाने वाला सर्वर, एसएमटीपी होस्ट से कनेक्ट हो सकता है या नहीं.

1. कनेक्शन की जांच करने के लिए, Windows कमांड लाइन या टर्मिनल में यह कमांड डालें:

   telnet smtp.gmail.com 587

2. अगर होस्ट कनेक्ट नहीं हो पाता है, तो एसएमटीपी सर्वर के इनग्रेस फ़ायरवॉल के नियमों और GCDS सर्वर के इग्रेस फ़ायरवॉल के नियमों की जांच करें.
3. पक्का करें कि आपने एसएमटीपी पोर्ट पर ट्रैफ़िक की अनुमति दी हो.

लॉग में सॉकेट को टीएलएस में बदलने से जुड़ी गड़बड़ी

सर्टिफ़िकेट रद्द करने की सूची (सीआरएल) की जांच करने की सुविधा बंद करें. ज़्यादा जानकारी के लिए, GCDS, सर्टिफ़िकेट रद्द करने की सूचियों की जांच कैसे करता है लेख पढ़ें.

किसी अन्य मशीन पर सेव की गई या किसी अन्य उपयोगकर्ता के तौर पर सेव की गई XML फ़ाइल को कैसे खोलें?

किसी दूसरी मशीन पर सेव की गई XML फ़ाइल को खोलने या उसी मशीन पर किसी दूसरे उपयोगकर्ता के तौर पर सेव की गई फ़ाइल को खोलने के निर्देशों के लिए, कॉन्फ़िगरेशन फ़ाइलों के साथ काम करना लेख पढ़ें.

मैं LDAP डायरेक्ट्री से डेटा कैसे एक्सपोर्ट करूं?

अगर GCDS के ट्रेस-लेवल के लॉग में मौजूद LDAP डेटा, LDAP सर्वर पर मौजूद डेटा से मेल नहीं खाता है (उदाहरण के लिए, कोई उपयोगकर्ता नहीं मिलता या किसी एट्रिब्यूट की वैल्यू सही नहीं है), तो LDAP डायरेक्ट्री से डेटा को LDIF फ़ॉर्मैट में एक्सपोर्ट करें. सहायता टीम, डेटा की तुलना GCDS के लॉग में मौजूद LDAP डेटा से कर सकती है.

डेटा एक्सपोर्ट करते समय, ldapsearch (Linux) या ldifde (Windows) जैसे LDAP क्वेरी टूल का इस्तेमाल करें. साथ ही, उन शर्तों को लागू करें जिनके साथ GCDS काम कर रहा है:

• GCDS के लिए कॉन्फ़िगर की गई कनेक्शन सेटिंग का ही इस्तेमाल करें.
• क्वेरी टूल को उसी मशीन से चलाएं जिस पर GCDS चल रहा है.
• GCDS LDAP की पुष्टि के लिए, एक ही उपयोगकर्ता नाम का इस्तेमाल करें.

उदाहरण

आपके GCDS लॉग में, उपयोगकर्ताओं के mail एट्रिब्यूट की जानकारी नहीं दिखती है. साथ ही, GCDS की खोज के नियम से जुड़ी सेटिंग ये हैं:

• बेस डीएन: ou=Ireland,dc=altostrat,dc=com
• स्कोप: Subtree
• खोज फ़िल्टर: (&(objectCategory=person)(objectClass=user))
• Server: dc01.altostrat.com
• पोर्ट: 636
• प्रोटोकॉल: LDAP+SSL
• Authentication user DN: cn=GCDS,ou=Users,dc=altostrat,dc=com

इन कमांड का इस्तेमाल करें:

• Linux: ldapsearch -v -b "ou=Ireland,dc=altostrat,dc=com" -s sub -h dc01.altostrat.com -p 636 -x -Z -D "cn=GCDS,ou=Users,dc=altostrat,dc=com" "(&(objectCategory=person)(objectClass=user))" mail givenname uniqueidentifier sn > out.ldif (आपको अपने सिस्टम के हिसाब से कमांड में बदलाव करना पड़ सकता है.)
• Windows: ldifde -f out.ldif -s dc01.altostrat.com -v -t 636 -d "ou=Ireland,dc=altostrat,dc=com" -r "(&(objectCategory=person)(objectClass=user))" -p SubTree -l mail,givenname,uniqueidentifier,sn -a "cn=GCDS,ou=Users,dc=altostrat,dc=com" PASSWORD (PASSWORD को GCDS में सेट किए गए LDAP उपयोगकर्ता के पासवर्ड से बदलें.)

अगर आउटपुट (out.ldif) में, प्रभावित उपयोगकर्ता के लिए mail एट्रिब्यूट मौजूद नहीं है, तो इसका मतलब है कि एलडीएपी इन्फ़्रास्ट्रक्चर में कोई समस्या है. यह समस्या, LDAP को ऐक्सेस करने के लिए इस्तेमाल किए जा रहे उपयोगकर्ता की अनुमतियों से जुड़ी हो सकती है. उदाहरण के लिए, OpenLDAP और Active Directory, दोनों में एट्रिब्यूट-लेवल की अनुमतियां सेट करने की अनुमति होती है. इसके अलावा, अगर 3268 या 3269 जैसे ग्लोबल कैटलॉग पोर्ट का इस्तेमाल किया जा रहा है, तो हो सकता है कि एट्रिब्यूट को ग्लोबल कैटलॉग में न दोहराया जाए.

अगर आउटपुट में, प्रभावित उपयोगकर्ता के लिए mail एट्रिब्यूट मौजूद है, तो Google Workspace की सहायता टीम को यह जानकारी दें:

• out.ldif फ़ाइल
• कमांड प्रॉम्प्ट या टर्मिनल विंडो का स्क्रीनशॉट, जिसमें आपने कमांड चलाई थी
  (पहले पासवर्ड हटाना न भूलें.)
• GCDS का ट्रेस-लेवल लॉग

क्या सिम्युलेटेड सिंक चलाने के लिए, मुझे सूचना सर्वर की ज़रूरत है?

सिमुलेटेड सिंक्रनाइज़ेशन चलाने के लिए, आपको ऐसे सर्वर की ज़रूरत होगी जो ईमेल भेज सके. अगर GCDS को मेल सर्वर मशीन पर चलाया जा रहा है, तो मेल सर्वर के लिए आईपी पते 127.0.0.1 का इस्तेमाल किया जा सकता है. अगर ऐसा नहीं होता है, तो ईमेल की सही जानकारी पाने के लिए, अपने ईमेल एडमिन से संपर्क करें.

GCDS, कमांड लाइन से सिंक क्यों नहीं कर रहा है?

अगर सिंक करने के लिए कमांड लाइन का इस्तेमाल किया जा रहा है और सिंक शुरू नहीं होता है, तो देखें कि आपने कमांड लाइन में -o या --oneinstance आर्ग्युमेंट का इस्तेमाल किया है या नहीं.

इनमें से किसी एक आर्ग्युमेंट का इस्तेमाल करने पर, GCDS, एक्सएमएल कॉन्फ़िगरेशन फ़ाइल से जुड़ी LOCK (.lock) फ़ाइल बनाता है. अगर उसी सर्वर पर कोई दूसरी LOCK फ़ाइल मिलती है, तो GCDS सिंक नहीं करेगा. इससे GCDS के एक साथ कई इंस्टेंस चलने से रोका जा सकेगा.

अगर GCDS का कोई और इंस्टेंस नहीं चल रहा है, तो सर्वर पर कोई दूसरी LOCK फ़ाइल देखें. फ़ाइल को मैन्युअल तरीके से मिटाएं और फिर से सिंक करने की कोशिश करें.

सिंक करने की प्रोसेस पूरी नहीं हुई. क्या यह एपीआई से जुड़ी कोई समस्या है?

अगर सिंक करने की प्रोसेस पूरी नहीं हुई है, जैसे कि किसी ग्रुप की पूरी सदस्यता सिंक नहीं हुई है, तो हो सकता है कि Directory API में कोई समस्या हो. यह पुष्टि करने के लिए कि समस्या GCDS प्रॉडक्ट से जुड़ी है या एपीआई से, डायरेक्ट्री एपीआई को मैन्युअल तरीके से कॉल करें और नतीजों की समीक्षा करें. एपीआई को मैन्युअल तरीके से कॉल करने के लिए, इनमें से कोई एक विकल्प चुनें.

पहला विकल्प: एपीआई के बारे में जानकारी देने वाले पेज का इस्तेमाल करना

1. Admin SDK API के बारे में जानकारी पर जाएं.
2. बाईं ओर, Directory API पर क्लिक करें. इसके बाद, REST रिसॉर्स के लिए, उस REST रिसॉर्स पर जाएं जिसके लिए आपको क्वेरी करनी है.
3. दाईं ओर, उस तरीके पर क्लिक करें जिसे आपको आज़माना है. इसके बाद, इसे आज़माएं पर क्लिक करें.

   अगर एपीआई के रेफ़रंस पेज पर इसे आज़माएं विकल्प नहीं दिखता है, तो दूसरा विकल्प: OAuth 2.0 Playground का इस्तेमाल करें पर जाएं.

4. वे एडमिन क्रेडेंशियल डालें जिनका इस्तेमाल करके आपने GCDS को अनुमति दी थी.

   ज़्यादा जानकारी के लिए, Google डोमेन की सेटिंग तय करना लेख पढ़ें.

5. जानकारी की समीक्षा करके पक्का करें कि एपीआई ने उम्मीद के मुताबिक जवाब दिया है.

दूसरा विकल्प: OAuth 2.0 Playground का इस्तेमाल करना

1. OAuth 2.0 Playground खोलें.
2. कोई विकल्प चुनें:
   • सूची से कोई स्कोप चुनें.
   • एपीआई रेफ़रंस पेज पर, अनुमति के स्कोप की सूची से कोई स्कोप कॉपी करें. इसके बाद, अपने स्कोप डालें फ़ील्ड में स्कोप चिपकाएं.
3. एपीआई को अनुमति दें पर क्लिक करें.
4. वे एडमिन क्रेडेंशियल डालें जिनका इस्तेमाल करके आपने GCDS को अनुमति दी थी.

   ज़्यादा जानकारी के लिए, Google डोमेन की सेटिंग तय करना लेख पढ़ें.

5. ऑथराइज़ेशन कोड को टोकन के लिए बदलें पर क्लिक करें.

   अगर प्रोसेस पूरी हो जाती है, तो आपको तीसरा चरण: एपीआई के लिए अनुरोध कॉन्फ़िगर करें पर रीडायरेक्ट कर दिया जाएगा.

6. मांगी गई जानकारी भरें.

   अहम जानकारी: आपको एपीआई के तरीके के रेफ़रंस वेबपेज पर ज़्यादातर जानकारी मिल सकती है.

7. अनुरोध भेजें पर क्लिक करें.
8. जानकारी की समीक्षा करके पक्का करें कि एपीआई ने उम्मीद के मुताबिक जवाब दिया है.

EntityDoesNotExist/EntityExists गड़बड़ियां या विवाद किस वजह से होते हैं?

अपनी एक्सएमएल कॉन्फ़िगरेशन फ़ाइल में, useDynamicMaxCacheLifetime विकल्प सेट करें. इस विकल्प से, GCDS को ज़्यादा से ज़्यादा आठ दिनों तक डेटा को कैश मेमोरी में सेव करने के लिए कॉन्फ़िगर किया जाता है. साथ ही, छोटे से लेकर मीडियम साइज़ के डेटा सेट में कैश मेमोरी को बार-बार मिटाने के लिए कॉन्फ़िगर किया जाता है. इससे, कैश मेमोरी में सेव किए गए डेटा के पुराने होने या नए डेटा से मेल न खाने की संभावना कम हो जाती है. GCDS 3.2.1 और इसके बाद के वर्शन से बनाए गए कॉन्फ़िगरेशन में, useDynamicMaxCacheLifetime विकल्प अपने-आप चालू हो जाता है.

ध्यान दें: ये गड़बड़ियां आम तौर पर तब होती हैं, जब आपके Google डोमेन में सीधे तौर पर बदलाव किए जाते हैं. GCDS का इस्तेमाल करके सिंक करते समय, आपको अपने Google डोमेन में सीधे तौर पर बदलाव नहीं करने चाहिए. इसके बजाय, अपनी LDAP डायरेक्ट्री में उपयोगकर्ताओं, ग्रुप, और अन्य इकाइयों में बदलाव करें. इसके बाद, GCDS का इस्तेमाल करके इन बदलावों को अपने Google डोमेन के साथ सिंक करें.

मैं मेमोरी से जुड़ी गड़बड़ियों को कैसे ठीक करूं?

अगर आपको मेमोरी से जुड़ी गड़बड़ियां दिख रही हैं, तो आपको Java Virtual Machine के लिए हीप साइज़ बढ़ाना होगा. GCDS की इंस्टॉलेशन डायरेक्ट्री में मौजूद, sync-cmd.vmoptions और config-manager.vmoptions फ़ाइलों में बदलाव करके, हीप साइज़ बढ़ाएं. इससे जुड़ी एंट्री कुछ इस तरह दिखती हैं:

• -Xmx1000m (हीप साइज़ के लिए मेमोरी की ज़्यादा से ज़्यादा जगह)
• -Xms64m (हीप साइज़ के लिए कम से कम मेमोरी)

sync-cmd.vmoptions और config-manager.vmoptions, दोनों फ़ाइलों में बदलाव करें, ताकि बदलाव sync-cmd और Configuration Manager, दोनों वर्शन पर लागू हो.

मेमोरी की मात्रा बढ़ाने के लिए, -Xmx नंबर में बदलाव करें. संख्या के बाद "m" का मतलब है कि मेमोरी को मेगाबाइट (एमबी) में मापा गया है. मेमोरी की सही मात्रा इस बात पर निर्भर करती है कि GCDS सर्वर के पास कितनी मेमोरी है और उसे सिंक्रनाइज़ेशन के लिए कितनी मेमोरी की ज़रूरत है. सही साइज़ सेट करने के लिए, आपको कई बार नंबर में बदलाव करना पड़ सकता है. GCDS को चलाने के लिए, ज़रूरी खाली रैम की मात्रा के बारे में ज़्यादा जानने के लिए, GCDS के लिए सिस्टम की ज़रूरी शर्तें पर जाएं.

कैश मेमोरी बंद होने पर, GCDS गड़बड़ी क्यों दिखाता रहता है?

यह समस्या, कॉन्फ़िगरेशन से जुड़ी किसी समस्या की वजह से हो सकती है. जैसे, बाहर रखने के नियम का गलत कॉन्फ़िगरेशन. इस तरह की गलत कॉन्फ़िगरेशन को GCDS की कैश मेमोरी में सेव करके छिपाया जा सकता है.

GCDS, आपकी Google सेवा (जैसे कि Google Workspace या Cloud Identity) के डेटा की कैश मेमोरी को ज़्यादा से ज़्यादा आठ दिनों तक सेव रखता है. कैश किए गए डेटा के साइज़ के आधार पर, GCDS कैश मेमोरी को ज़्यादा बार मिटा सकता है. हालांकि, अगर कैश मेमोरी को नहीं मिटाया जाता है, तो हो सकता है कि आपको आठ दिनों तक अपने अपडेट न दिखें.

उदाहरण के लिए, LDAP डेटा सिंक किया जाता है और Google की सेवा (जैसे कि Google Workspace या Cloud Identity) के लिए नया ग्रुप बनाया जाता है. इसके बाद, उस ग्रुप को आने वाले समय में होने वाले सिंक से बाहर रखने के लिए, एक्सक्लूज़न का नियम बनाएं. बहिष्करण का नियम गलत तरीके से कॉन्फ़िगर किया गया है. इसलिए, यह काम नहीं करेगा. हालांकि, कैश मेमोरी में सेव किए गए डेटा पर बाद में किए गए सिंक कॉल और ग्रुप, आपकी Google सेवा में बने रहते हैं. कैश मेमोरी मिटाकर फिर से सिंक करने पर, गलत कॉन्फ़िगरेशन की वजह से ग्रुप को Google की सेवा से हटा दिया जाता है.

कैश मेमोरी को मैन्युअल तरीके से मिटाने के लिए:

• Configuration Manager से सिंक करें. साथ ही, सिंक करते समय कैश मेमोरी मिटाने का विकल्प चुनें.
• कमांड से सिंक करें और -f आर्ग्युमेंट का इस्तेमाल करके, कैश मेमोरी को फ़्लश करें.
• maxCacheLifetime वैल्यू को 0 पर सेट करने के लिए, एक्सएमएल कॉन्फ़िगरेशन फ़ाइल में बदलाव करें.

अहम जानकारी: कैश मेमोरी को फ़्लश करने से, सिंक्रनाइज़ेशन में लगने वाला समय काफ़ी बढ़ सकता है.

GCDS, ऐसे Google उपयोगकर्ताओं को क्यों बना रहा है जो पहले से मौजूद हैं?

अगर आपको 409: Entity already exists गड़बड़ी का मैसेज मिलता है, तो इसका मतलब है कि GCDS ऐसे Google उपयोगकर्ता खाते बनाने की कोशिश कर रहा है जो पहले से मौजूद हैं. अगर आपको बाद के सिंक में गड़बड़ी नहीं दिखती है, तो हो सकता है कि GCDS कैश मेमोरी पुरानी हो गई हो. ऐसे में, गड़बड़ी को अनदेखा किया जा सकता है.

अगर यह समस्या हर सिंक या हर कुछ दिनों में होती है, तो इसकी ये वजहें हो सकती हैं:

• Google उपयोगकर्ता को बाहर रखने का नियम बहुत ज़्यादा सामान्य है. यह नियम, LDAP डायरेक्ट्री में मौजूद कुछ ऐसे Google उपयोगकर्ताओं से मेल खाता है.
• क्वेरी बहुत सीमित है—क्वेरी, Google के उन उपयोगकर्ताओं से मेल नहीं खाती जो LDAP डायरेक्ट्री में भी मौजूद हैं.

इन दोनों ही स्थितियों में, GCDS उन Google उपयोगकर्ताओं को अनदेखा कर सकता है जो पहले से मौजूद हैं. अगर वे उपयोगकर्ता, LDAP उपयोगकर्ता खोज के नियम के नतीजों में मौजूद हैं, तो GCDS उन्हें आपके Google खाते में बनाने की कोशिश करता है.

इस समस्या को हल करने के लिए, बाहर रखने के नियम या खोज क्वेरी में बदलाव करें. इसके अलावा, अगर आपको GCDS को अपनी LDAP डायरेक्ट्री में मौजूद उपयोगकर्ताओं को पूरी तरह से अनदेखा करने के लिए कहना है, तो LDAP उपयोगकर्ता खोजने के नियम में बदलाव करें या LDAP उपयोगकर्ता को बाहर रखने का नियम बनाएं. ज़्यादा जानकारी के लिए, डेटा को बाहर रखने के नियमों और क्वेरी की मदद से डेटा को शामिल न करना पर जाएं.

कुछ उपयोगकर्ताओं को ग्रुप के सदस्यों के तौर पर क्यों सिंक नहीं किया जाता?

GCDS, INDEPENDENT_GROUP_SYNC को डिफ़ॉल्ट रूप से चालू करता है, ताकि ग्रुप के सदस्यों को किसी भी उपयोगकर्ता की खोज से जुड़े नियमों के नतीजों से अलग सिंक किया जा सके. अगर ग्रुप सिंक करने के लिए, सदस्य-रेफ़रंस एट्रिब्यूट का इस्तेमाल किया जा रहा है, तो GCDS, LDAP डायरेक्ट्री में मौजूद हर उपयोगकर्ता का ईमेल पता ढूंढने की कोशिश करता है. भले ही, उपयोगकर्ता को खोजने से जुड़े कोई नियम लागू न हों.

अगर आपको सिर्फ़ उपयोगकर्ता की खोज से जुड़े नियमों के नतीजों के आधार पर ग्रुप के सदस्यों को सिंक करना है, तो अपनी कॉन्फ़िगरेशन XML फ़ाइल से INDEPENDENT_GROUP_SYNC को हटाएं. GCDS:

• यह कुकी, ग्रुप की सदस्यता तय करने के लिए उपयोगकर्ता की खोज से जुड़े नियमों के नतीजों का इस्तेमाल करती है
• सिर्फ़ उन उपयोगकर्ताओं को ग्रुप के सदस्यों के तौर पर सिंक करता है जिन्हें उपयोगकर्ता सिंक करने की सुविधा में शामिल किया गया है
• उपयोगकर्ता के खोज नियमों को लागू करता है. भले ही, आपने सामान्य सेटिंग में उपयोगकर्ता खाते को सिंक करने की सुविधा बंद कर दी हो

  (हालांकि, अगर ज़रूरी शर्तें पूरी करने वाले उपयोगकर्ता, ग्रुप के सदस्य भी हैं, तो नतीजे Google के साथ उपयोगकर्ताओं के तौर पर नहीं, बल्कि ग्रुप के सदस्यों के तौर पर सिंक होते हैं.)

आम तौर पर, आपको इस तरह से सिंक नहीं करना चाहिए. खास तौर पर, अगर आपको शेयर किए गए संपर्कों को सिंक करना है और आपके ग्रुप में ऐसे सदस्य हैं जो संपर्क हैं. इस मामले में, संपर्कों को ग्रुप के सदस्यों के तौर पर सिंक नहीं किया जाएगा.

हर सिंक के बाद, कुछ उपयोगकर्ताओं या ग्रुप को फिर से क्यों बनाया जा रहा है?

यह समस्या तब होती है, जब ग्रुप के नाम के एट्रिब्यूट के तौर पर कॉन्फ़िगर किए गए LDAP एट्रिब्यूट में पूरा ईमेल पता शामिल न हो. इस समस्या को हल करने के लिए, ग्रुप सर्च करने के नियमों की जांच करें. साथ ही, पक्का करें कि GCDS, ग्रुप के नामों के लिए पूरे ईमेल पते का इस्तेमाल करता हो. इनमें से किसी एक तरीके का इस्तेमाल करें:

• ग्रुप के नाम वाले एट्रिब्यूट को किसी ऐसे दूसरे LDAP एट्रिब्यूट पर सेट करें जो हर ग्रुप के लिए पूरा ईमेल पता बताता हो. जैसे, mail.
• Google की डोमेन सेटिंग में जाकर, एलडीएपी ईमेल पतों में डोमेन नेम बदलें को चालू करें. इससे, आपके ग्रुप के नाम का एट्रिब्यूट, Google के ग्रुप के नामों से मैच हो जाएगा.
• ग्रुप के नाम में डोमेन का नाम जोड़ने के लिए, ग्रुप सर्च रूल में ग्रुप के नाम का सफ़िक्स तय करें.

Active Directory में 1,500 से ज़्यादा सदस्यों वाले ग्रुप सही तरीके से सिंक नहीं हो रहे हैं

पक्का करें कि आपने LDAP कॉन्फ़िगरेशन सेक्शन के सर्वर टाइप फ़ील्ड में, MS Active Directory चुना हो.

मैं "एलडीएपी ईमेल पतों में डोमेन नेम बदलें" सुविधा का इस्तेमाल कैसे करूं?

इस विकल्प का इस्तेमाल तब किया जाता है, जब LDAP डायरेक्ट्री में मौजूद ईमेल पते, आपके Google डोमेन से अलग डोमेन में हों. इसे XML फ़ाइल में SUPPRESS_DOMAIN के तौर पर दिखाया जाता है. इसे चालू करने पर, GCDS उन सभी ईमेल पतों से डोमेन का हिस्सा हटा देता है जिन्हें वह पढ़ता है.

डोमेन नेम के बिना ही प्रोसेसिंग की जाती है. अगर ईमेल पतों के आधार पर बाहर रखने के नियमों का इस्तेमाल किया जाता है, तो आपको बाहर रखने के नियम के लिए, ईमेल पते के सिर्फ़ लोकल पार्ट पर विचार करना होगा.

उदाहरण के लिए, अगर आपने एलडीएपी ईमेल पतों में डोमेन के नाम बदलें सेटिंग बंद की है और आपको सटीक मिलान वाली एक्सक्लूज़न सूची बनानी है, तो उपयोगकर्ता के ईमेल पते के तौर पर luka@example.com डालें. अगर आपने एलडीएपी ईमेल पतों में डोमेन के नाम बदलें सेटिंग चालू की है, तो luka का इस्तेमाल करें. luka@example.com से मैच करने की कोशिश करने पर, यह काम नहीं करेगा. ऐसा इसलिए, क्योंकि तुलना करने से पहले @example.com हटा दिया जाता है.

क्या स्टैटिक और डाइनैमिक ग्रुप को नेस्ट किया जा सकता है?

GCDS का इस्तेमाल करके ग्रुप बनाते समय, डाइनैमिक ग्रुप को स्टैटिक ग्रुप के नीचे (या स्टैटिक ग्रुप को डाइनैमिक ग्रुप के नीचे) नेस्ट नहीं किया जा सकता. GCDS को स्टैटिक ग्रुप के लिए अलग से क्वेरी करने की ज़रूरत होती है. हालांकि, सभी नेस्ट किए गए ग्रुप, एक ही क्वेरी का हिस्सा होने चाहिए.

डाइनैमिक ग्रुप को स्टैटिक ग्रुप के तौर पर लागू करने का तरीका ढूंढें. इसके लिए, ऐसे टास्क को अपने-आप होने की सुविधा चालू करें जो समय-समय पर हर डाइनैमिक ग्रुप से क्वेरी करता हो, ताकि डायरेक्ट्री में स्टैटिक ग्रुप की जानकारी अपने-आप भर जाए. इसके बाद, GCDS, स्टैटिक ग्रुप का इस्तेमाल करके उपयोगकर्ताओं को ऐक्सेस दे सकता है. इन स्टैटिक ग्रुप को डाइनैमिक ग्रुप से बनाया जाता है. GCDS, डाइनैमिक ग्रुप का इस्तेमाल करके उपयोगकर्ताओं को ऐक्सेस नहीं दे सकता.

मुझे LDAP क्वेरी से अनचाहे नतीजे क्यों मिले?

LDAP क्वेरी के नतीजे, Configuration Manager की सेटिंग और LDAP सर्वर पर निर्भर करते हैं. अगर एलडीएपी खोज के नियम से आपको अनचाहा नतीजा मिलता है, तो समस्या हल करने के लिए यह सलाह देखें. सुनिश्चित करें:

• Configuration Manager में LDAP क्वेरी सही तरीके से सेट अप की गई हो—सर्च का नियम सेट अप करते समय, पुष्टि करने के लिए LDAP क्वेरी की जांच करें पर क्लिक करें. ज़्यादा जानकारी के लिए, डेटा सिंक करने के लिए, LDAP खोज के नियमों का इस्तेमाल करना पर जाएं.
• एक से ज़्यादा क्वेरी एक-दूसरे से अलग नहीं होनी चाहिए—देखें कि आपने कोई ऐसी खोज या बाहर रखने का नियम सेट अप न किया हो जिससे क्वेरी का नतीजा बदल जाता हो.
• LDAP सर्वर के लिए, पुष्टि किए गए उपयोगकर्ता के पास ज़रूरी अनुमतियां हों—पक्का करें कि LDAP सर्वर की पुष्टि करने के लिए इस्तेमाल किया गया एडमिन, उसी सर्वर पर कमांड लाइन का इस्तेमाल कर सकता हो. LDAP सर्वर पर क्वेरी आज़माएं और नतीजों की पुष्टि करें.

ग्रुप नहीं बनाया जा सका

आपको ग्रुप ... नहीं बनाया जा सका गड़बड़ी का मैसेज दिख सकता है.GCDS लॉग में, मैसेज: इस संसाधन/एपीआई को ऐक्सेस करने की अनुमति नहीं है.

समस्या हल करने के लिए, देखें कि उपयोगकर्ता और ग्रुप के ईमेल पतों के लिए, Active Directory (AD) एट्रिब्यूट में मौजूद डोमेन, आपके सुपर एडमिन खाते के इस्तेमाल किए गए डोमेन से मेल खाता हो.

GCDS के साथ सिंक करने के बाद, मुझे अपने डोमेन डायरेक्ट्री में डुप्लीकेट संपर्क क्यों दिखते हैं?

आम तौर पर, यह समस्या तब होती है, जब शेयर किए गए संपर्कों को सिंक किया जा रहा हो और खोज के नियम गलत तरीके से बनाए गए हों.

GCDS के साथ दो तरह के काम के ऑब्जेक्ट सिंक किए जा सकते हैं:

• उपयोगकर्ता प्रोफ़ाइलें—आपके Google डोमेन के ऐसे उपयोगकर्ता जिनके पास फ़ोन नंबर या पते जैसा अतिरिक्त डेटा है. किसी प्रोफ़ाइल को सिर्फ़ उस उपयोगकर्ता के लिए सिंक किया जा सकता है जो आपके डोमेन में मौजूद है.
• शेयर किए गए संपर्क—बाहरी पक्षों के ऐसे संपर्क जिनसे आपके डोमेन के उपयोगकर्ताओं को संपर्क करना होता है.

इस समस्या को हल करने के लिए, शेयर किए गए संपर्क खोजने के नियमों में बदलाव करें, ताकि आपके डोमेन के उपयोगकर्ताओं को खोज के नतीजों से हटाया जा सके. अगली बार सिंक करने पर, GCDS डुप्लीकेट संपर्कों को मिटाने की कोशिश करता है. पहली बार सिंक करने के लिए, आपको शेयर किए गए संपर्क मिटाने की सीमा में बदलाव करना पड़ सकता है.

कुछ उपयोगकर्ताओं को Google Calendar में, उनके काम की मुख्य जगह की जानकारी क्यों नहीं दिखती?

कुछ मामलों में, मीटिंग शेड्यूल या व्यवस्थित करते समय उपयोगकर्ताओं को Google Calendar में, उनके काम करने की मुख्य जगह नहीं दिखती.

अगर आपको यह समस्या दिखती है, तो पक्का करें कि जगह का टाइप और क्षेत्र एट्रिब्यूट की वैल्यू "डेस्क" पर सेट हो.

खोज के नियम के मुताबिक कोई भी नतीजा क्यों नहीं मिल रहा है?

अगर आपको खोज के नतीजों से जुड़ी समस्याएं आ रही हैं, तो:

• नियम का स्कोप. आपको स्कोप को सब-ट्री पर सेट करना पड़ सकता है.
• आपने खोज के लिए सही नियम का इस्तेमाल किया हो.
• इस्तेमाल किए गए एट्रिब्यूट मौजूद हैं और दिख रहे हैं.

आपकी LDAP क्वेरी. पुष्टि करें कि आपके LDAP सर्वर पर की गई क्वेरी में, उसी एडमिन उपयोगकर्ता नाम का इस्तेमाल किया जा रहा हो जिसे GCDS में कॉन्फ़िगर किया गया है.

ज़्यादा जानकारी के लिए, डेटा सिंक करने के लिए, LDAP खोज के नियमों का इस्तेमाल करना लेख पढ़ें.

अपवाद का नियम बनाते समय, मुझे 'ठीक है' बटन क्यों नहीं दिख रहा है?

ऐसा हो सकता है कि आपने स्क्रीन के हिसाब से बहुत बड़े फ़ॉन्ट का इस्तेमाल किया हो. डायलॉग बॉक्स, बड़े या बहुत बड़े फ़ॉन्ट के साथ काम नहीं करता. फ़ॉन्ट का साइज़ बदलें या सीधे तौर पर अपनी XML फ़ाइल में बदलाव करें.