সাধারণ GCDS সমস্যা সমাধান করুন

কনফিগারেশন ম্যানেজার ব্যবহার করে একটি কনফিগারেশনের সমস্যা সমাধান করুন

যদি আপনার সিঙ্ক্রোনাইজেশন সঠিকভাবে চালাতে সমস্যা হয়, তাহলে কনফিগারেশন ম্যানেজারে কনফিগারেশন তথ্য সঠিক কিনা তা নিশ্চিত করুন এবং কোন পরীক্ষাগুলি ব্যর্থ হয়েছে তা লক্ষ্য করুন:

1. কনফিগারেশন ম্যানেজারে , সিঙ্ক্রোনাইজেশন কনফিগার করার জন্য আপনি যে XML ফাইলটি ব্যবহার করছেন তা খুলুন।
2. LDAP সংযোগ পৃষ্ঠায়, আপনার LDAP সার্ভারের সাথে সংযোগ করতে পারছেন কিনা তা নিশ্চিত করতে Test Connections এ ক্লিক করুন।
3. আপনি একটি পরীক্ষামূলক বিজ্ঞপ্তি পাঠাতে পারেন তা নিশ্চিত করতে বিজ্ঞপ্তি পৃষ্ঠায়, পরীক্ষামূলক বিজ্ঞপ্তিতে ক্লিক করুন।
4. সিঙ্ক পৃষ্ঠায়, সিমুলেট সিঙ্ক ক্লিক করে নিশ্চিত করুন যে আপনি সমস্ত প্রয়োজনীয় ক্ষেত্র পূরণ করেছেন এবং সিঙ্ক্রোনাইজেশন চলছে।

API অনুরোধের জন্য আমি কীভাবে সম্পূর্ণ HTTP লগিং চালু করব?

বিরল ক্ষেত্রে, GCDS-এ ট্রেস-লেভেল লগিং চালু করার পাশাপাশি, সাপোর্ট আপনাকে সম্পূর্ণ HTTP লগিং চালু করতে বলতে পারে। GCDS-এর করা সঠিক API অনুরোধ এবং Google API-এর দ্বারা প্রদত্ত প্রতিক্রিয়া দেখতে সম্পূর্ণ HTTP লগিং ব্যবহার করা হয়।

গুরুত্বপূর্ণ : সম্পূর্ণ HTTP লগে অত্যন্ত সংবেদনশীল তথ্য থাকতে পারে। সাপোর্টে লগ পাঠানোর আগে যেকোনো সংবেদনশীল তথ্য (যেমন বর্তমান রিফ্রেশ_টোকেন বা অ্যাক্সেস_টোকেন ক্ষেত্র) সরিয়ে ফেলুন।

সম্পূর্ণ HTTP লগিং চালু করতে:

1. নিশ্চিত করুন যে GCDS sync-cmd অথবা কনফিগারেশন ম্যানেজারের সাথে চলছে না।
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 KB পর্যন্ত সীমাবদ্ধ। যদি আপনি এমন একটি লগ এন্ট্রি দেখতে পান যা সেই সীমা অতিক্রম করার কারণে কেটে ফেলা হয়েছে, তাহলে একটি ডিবাগিং প্রক্সি ব্যবহার করুন, যেমন Fiddler।

ফিডলার সক্ষম করতে, এই পদক্ষেপগুলি অনুসরণ করুন:

1. GCDS ইনস্টল করা পাথে যান, উদাহরণস্বরূপ, C:\Program Files\Google Cloud Directory Sync ।
2. CRL চেক বন্ধ করতে .vmoptions ফাইলগুলিতে (যেমন, config-manager.vmoptions অথবা sync-cmd.vmoptions) নিম্নলিখিত ফ্ল্যাগগুলি যোগ করুন:

   -Dcom.sun.security.enableCRLDP=false

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

পরিবর্তনগুলি কার্যকর হওয়ার জন্য GCDS পুনরায় চালু করুন।

1. আপনার Google ডোমেন কনফিগারেশনের প্রক্সি সেটিংসে Fiddler কে প্রক্সি হিসেবে কনফিগার করুন। হোস্টনেম ফিল্ডে, স্থানীয় IP ঠিকানা 127.0.0.1 যোগ করুন। ডিফল্ট পোর্ট হল 8888 , তবে আপনি Fiddler খুলে, Options > Connections-এ গিয়ে এবং "Fiddler Classiclistens on port" ফিল্ডে মান পরীক্ষা করে এটি নিশ্চিত করতে পারেন।

যদি আপনি লিনাক্সে GCDS ব্যবহার করেন, তাহলে আপনি Windows বিশ্বস্ত সার্টিফিকেট স্টোর ব্যবহার করতে পারবেন না, তাই আপনাকে GCDS এর জাভা ট্রাস্ট স্টোরে Fiddler রুট সার্টিফিকেট আমদানি করতে হবে। এই পদক্ষেপগুলি সম্পর্কে বিস্তারিত জানতে, সার্টিফিকেট-সম্পর্কিত সমস্যাগুলির সমাধান করুন বিভাগে যান।

SMTP রিলে হোস্ট সেট আপ করতে সমস্যা হচ্ছে

আপনার বিজ্ঞপ্তিগুলির জন্য SMTP রিলে হোস্ট সেট আপ করতে যদি আপনার সমস্যা হয়, তাহলে নিম্নলিখিত সমস্যা সমাধানের পদক্ষেপগুলি চেষ্টা করে দেখুন।

সংযোগ ব্যর্থ হয়েছে এবং অজানা SMTP হোস্ট বার্তা

1. একটি কমান্ড প্রম্পট খুলুন।
2. SMTP সার্ভারের কনফিগার করা হোস্ট নামটি কোনও IP ঠিকানায় সমাধান হচ্ছে কিনা তা পরীক্ষা করতে, নিম্নলিখিত কমান্ডটি প্রবেশ করান:

   nslookup smtp-host-name .com সম্পর্কে

সংযোগ ব্যর্থ হয়েছে এবং SMTP হোস্ট বার্তার সাথে সংযোগ করা যায়নি।

GCDS চালিত সার্ভারটি SMTP হোস্টের সাথে সংযোগ করতে পারে কিনা তা পরীক্ষা করুন।

1. সংযোগ পরীক্ষা করতে, উইন্ডোজ কমান্ড লাইন বা টার্মিনাল থেকে, নিম্নলিখিত কমান্ডটি প্রবেশ করান:

   টেলনেট smtp.gmail.com 587

2. যদি হোস্ট সংযোগ করতে না পারে, তাহলে SMTP সার্ভারের ইনগ্রেস ফায়ারওয়াল নিয়ম এবং GCDS সার্ভারের ইগ্রেস ফায়ারওয়াল নিয়ম পরীক্ষা করুন।
3. নিশ্চিত করুন যে আপনি SMTP পোর্টে ট্র্যাফিকের অনুমতি দিয়েছেন।

লগে সকেটকে TLS ত্রুটিতে রূপান্তর করা যায়নি

সার্টিফিকেট প্রত্যাহার তালিকা (CRL) চেক বন্ধ করুন। বিস্তারিত জানার জন্য, কীভাবে GCDS সার্টিফিকেট প্রত্যাহার তালিকা পরীক্ষা করে দেখুন।

অন্য মেশিনে বা অন্য ব্যবহারকারী হিসেবে সংরক্ষিত XML ফাইলটি কীভাবে খুলব?

ভিন্ন মেশিনে সংরক্ষিত XML ফাইলটি কীভাবে খুলবেন, অথবা একই মেশিনে ভিন্ন ব্যবহারকারী হিসেবে কীভাবে খুলবেন তার নির্দেশাবলীর জন্য কনফিগারেশন ফাইলের সাথে কাজ করুন দেখুন।

LDAP ডিরেক্টরি থেকে আমি কীভাবে ডেটা রপ্তানি করব?

যদি GCDS ট্রেস-লেভেল লগের LDAP ডেটা LDAP সার্ভারে আপনার প্রত্যাশার সাথে মেলে না (উদাহরণস্বরূপ, কোনও ব্যবহারকারী খুঁজে পাওয়া যায় না বা কোনও বৈশিষ্ট্যের সঠিক মান নেই), তাহলে LDAP ডিরেক্টরি থেকে LDIF ফর্ম্যাটে ডেটা রপ্তানি করুন। সাপোর্ট GCDS লগ থেকে LDAP ডেটার সাথে ডেটা তুলনা করতে পারে।

যখন আপনি ডেটা এক্সপোর্ট করেন, তখন ldapsearch (Linux) অথবা ldifde (Windows) এর মতো LDAP কোয়েরি টুল ব্যবহার করুন এবং GCDS যে শর্তগুলির সাথে চলছে সেই একই শর্তগুলি অনুকরণ করুন:

• GCDS যে সংযোগ সেটিংস ব্যবহার করার জন্য কনফিগার করা হয়েছে, সেই একই সংযোগ সেটিংস ব্যবহার করুন।
• GCDS যে মেশিনে চলছে সেই মেশিন থেকেই কোয়েরি টুলটি চালান।
• GCDS LDAP প্রমাণীকরণের জন্য একই ব্যবহারকারীর নাম ব্যবহার করুন।

উদাহরণ

আপনার GCDS লগগুলি আপনার ব্যবহারকারীদের মেইল ​​অ্যাট্রিবিউট দেখায় না এবং আপনার GCDS অনুসন্ধান নিয়ম সেটিংস হল:

• বেস DN: ou=আয়ারল্যান্ড,dc=altostrat,dc=com
• ব্যাপ্তি: সাবট্রি
• অনুসন্ধান ফিল্টার: (&(objectCategory=person)(objectClass=user))
• সার্ভার: dc01.altostrat.com
• পোর্ট: ৬৩৬
• প্রোটোকল: LDAP+SSL
• প্রমাণীকরণ ব্যবহারকারী DN: cn=GCDS,ou=ব্যবহারকারী,dc=altostrat,dc=com

এই কমান্ডগুলি ব্যবহার করুন:

• লিনাক্স: 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 (আপনার সিস্টেমের উপর নির্ভর করে কমান্ডটি পরিবর্তন করতে হতে পারে।)
• উইন্ডোজ: 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 (GCDS-এ সেট করা LDAP ব্যবহারকারীর পাসওয়ার্ড দিয়ে PASSWORD প্রতিস্থাপন করুন।)

যদি আউটপুট (out.ldif) তে কোন প্রভাবিত ব্যবহারকারীর জন্য মেইল ​​অ্যাট্রিবিউট না থাকে, তাহলে LDAP পরিকাঠামোতে সমস্যা আছে। এটি LDAP অ্যাক্সেস করার জন্য আপনি যে ব্যবহারকারীর অনুমতি ব্যবহার করছেন তার সাথে সম্পর্কিত হতে পারে (উদাহরণস্বরূপ, OpenLDAP এবং Active Directory উভয়ই অ্যাট্রিবিউট-লেভেল অনুমতি সেট করার অনুমতি দেয়)। অথবা যদি আপনি 3268 বা 3269 এর মতো গ্লোবাল ক্যাটালগ পোর্ট ব্যবহার করেন তবে অ্যাট্রিবিউটটি গ্লোবাল ক্যাটালগে প্রতিলিপি নাও হতে পারে।

যদি আউটপুটে কোনও প্রভাবিত ব্যবহারকারীর জন্য মেইল ​​অ্যাট্রিবিউট থাকে, তাহলে Google Workspace সহায়তায় নিম্নলিখিত বিবরণগুলি প্রদান করুন:

• out.ldif ফাইলটি
• কমান্ড প্রম্পট বা টার্মিনাল উইন্ডোর একটি স্ক্রিনশট যেখানে আপনি কমান্ডটি চালান।
  (প্রথমে পাসওয়ার্ডটি মুছে ফেলতে ভুলবেন না।)
• GCDS ট্রেস-লেভেল লগ

সিমুলেটেড সিঙ্ক চালানোর জন্য কি আমার একটি নোটিফিকেশন সার্ভারের প্রয়োজন?

একটি সিমুলেটেড সিঙ্ক্রোনাইজেশন চালানোর জন্য, আপনার এমন একটি সার্ভারের প্রয়োজন যা মেল পাঠাতে সক্ষম। যদি আপনি একটি মেল সার্ভার মেশিনে GCDS চালান, তাহলে আপনি আপনার মেল সার্ভারের জন্য IP ঠিকানা 127.0.0.1 ব্যবহার করতে পারেন। অন্যথায়, সঠিক মেল তথ্যের জন্য আপনার মেল প্রশাসকের সাথে যোগাযোগ করুন।

কেন GCDS কমান্ড লাইন থেকে একটি সিঙ্ক চালাচ্ছে না?

যদি আপনি কমান্ড লাইন ব্যবহার করে সিঙ্ক চালান এবং সিঙ্ক শুরু না হয়, তাহলে কমান্ড লাইনে -o অথবা --oneinstance আর্গুমেন্ট ব্যবহার করেছেন কিনা তা পরীক্ষা করে দেখুন।

যদি আপনি এই আর্গুমেন্টগুলির মধ্যে একটি ব্যবহার করেন, তাহলে GCDS XML কনফিগারেশন ফাইলের সাথে যুক্ত একটি LOCK (.lock) ফাইল তৈরি করে। এবং, যদি একই সার্ভারে অন্য একটি LOCK ফাইল পাওয়া যায়, তাহলে GCDS একসাথে একাধিক GCDS চলমান প্রতিরোধ করার জন্য সিঙ্ক চালাবে না।

যদি GCDS চালু থাকার অন্য কোনও উদাহরণ না থাকে, তাহলে সার্ভারে অন্য কোনও LOCK ফাইল আছে কিনা তা পরীক্ষা করুন। ফাইলটি ম্যানুয়ালি মুছে ফেলুন এবং আবার সিঙ্ক চালানোর চেষ্টা করুন।

আমার সিঙ্ক অসম্পূর্ণ ছিল। এটি কি কোনও API সমস্যা হতে পারে?

যদি আপনার সিঙ্ক অসম্পূর্ণ থাকে, উদাহরণস্বরূপ, কোনও গ্রুপের সম্পূর্ণ সদস্যপদ সিঙ্ক না হয়, তাহলে ডিরেক্টরি API-তে সমস্যা হতে পারে। সমস্যাটি GCDS পণ্যের পরিবর্তে কোনও API-এর সাথে সম্পর্কিত কিনা তা যাচাই করতে, ডিরেক্টরি API-তে ম্যানুয়ালি কল করুন এবং ফলাফলগুলি পর্যালোচনা করুন। API-তে ম্যানুয়ালি কল করতে, দুটি বিকল্পের মধ্যে একটি বেছে নিন।

বিকল্প ১: API রেফারেন্স পৃষ্ঠা ব্যবহার করুন

1. অ্যাডমিন SDK API রেফারেন্স ওভারভিউতে যান।
2. বাম দিকে, Directory API এ ক্লিক করুন, তারপর, REST Resources এর জন্য, আপনি যে REST Resource টি জিজ্ঞাসা করতে চান সেখানে যান।
3. ডানদিকে, আপনি যে পদ্ধতিটি চেষ্টা করতে চান তাতে ক্লিক করুন এবং তারপর চেষ্টা করুন ক্লিক করুন।

   যদি API রেফারেন্স পৃষ্ঠাটি "Try it" না দেখায়, তাহলে বিকল্প 2: Use the OAuth 2.0 Playground-এ যান।

4. GCDS অনুমোদনের জন্য আপনি যে অ্যাডমিন শংসাপত্রগুলি ব্যবহার করেছিলেন তা লিখুন।

   বিস্তারিত জানার জন্য, আপনার Google ডোমেন সেটিংস নির্ধারণ করুন এ যান।

5. API প্রত্যাশা অনুযায়ী সাড়া দিয়েছে কিনা তা নিশ্চিত করতে তথ্য পর্যালোচনা করুন।

বিকল্প ২: OAuth 2.0 খেলার মাঠ ব্যবহার করুন

1. OAuth 2.0 খেলার মাঠ খুলুন।
2. একটি বিকল্প বেছে নিন:
   • তালিকা থেকে একটি সুযোগ নির্বাচন করুন।
   • API রেফারেন্স পৃষ্ঠায় Authorization স্কোপ তালিকা থেকে একটি স্কোপ কপি করুন। তারপর, "আপনার নিজস্ব স্কোপ ইনপুট করুন" ক্ষেত্রে স্কোপটি পেস্ট করুন।
3. API গুলি অনুমোদন করুন ক্লিক করুন।
4. GCDS অনুমোদনের জন্য আপনি যে অ্যাডমিন শংসাপত্রগুলি ব্যবহার করেছিলেন তা লিখুন।

   বিস্তারিত জানার জন্য, আপনার Google ডোমেন সেটিংস নির্ধারণ করুন এ যান।

5. টোকেনের জন্য এক্সচেঞ্জ অনুমোদন কোডে ক্লিক করুন।

   যদি প্রক্রিয়াটি সফল হয়, তাহলে আপনাকে ধাপ 3: API-তে অনুরোধ কনফিগার করতে পুনঃনির্দেশিত করা হবে।

6. অনুরোধকৃত তথ্য পূরণ করুন।

   টিপস : আপনি বেশিরভাগ তথ্য API পদ্ধতির রেফারেন্স ওয়েবপেজে খুঁজে পেতে পারেন।

7. অনুরোধ পাঠান ক্লিক করুন।
8. API প্রত্যাশা অনুযায়ী সাড়া দিয়েছে কিনা তা নিশ্চিত করতে তথ্য পর্যালোচনা করুন।

EntityDoesNotExist/EntityExists ত্রুটি বা দ্বন্দ্বের কারণ কী?

আপনার XML কনফিগারেশন ফাইলে, useDynamicMaxCacheLifetime বিকল্পটি সেট করুন। এই বিকল্পটি GCDS কে সর্বোচ্চ 8 দিনের জন্য ডেটা ক্যাশে করার জন্য কনফিগার করে এবং ছোট থেকে মাঝারি ডেটা সেটগুলিতে ক্যাশে আরও ঘন ঘন সাফ করে যাতে ক্যাশে করা ডেটা অচল হয়ে যাওয়ার বা নতুন ডেটার সাথে বিরোধিতার সম্ভাবনা কম হয়। GCDS 3.2.1 এবং তার পরবর্তী সংস্করণ দিয়ে তৈরি কনফিগারেশনে useDynamicMaxCacheLifetime বিকল্পটি স্বয়ংক্রিয়ভাবে কাজ করে।

দ্রষ্টব্য: এই ত্রুটিগুলি সাধারণত তখন ঘটে যখন আপনার Google ডোমেনে সরাসরি পরিবর্তন করা হয়। সিঙ্ক করার জন্য GCDS ব্যবহার করার সময়, আপনার Google ডোমেনে সরাসরি পরিবর্তন করা এড়িয়ে চলা উচিত। পরিবর্তে, আপনার LDAP ডিরেক্টরিতে ব্যবহারকারী, গোষ্ঠী এবং অন্যান্য সত্তাগুলিতে পরিবর্তন করুন। তারপর, আপনার Google ডোমেনে এই পরিবর্তনগুলি সিঙ্ক করতে GCDS ব্যবহার করুন।

মেমোরি-সম্পর্কিত ত্রুটিগুলি আমি কীভাবে ঠিক করতে পারি?

যদি আপনি মেমোরি-সম্পর্কিত ত্রুটি দেখতে পান, তাহলে আপনাকে জাভা ভার্চুয়াল মেশিনের জন্য হিপ সাইজ বাড়াতে হবে। GCDS এর ইনস্টলেশন ডিরেক্টরিতে sync-cmd.vmoptions এবং config-manager.vmoption ফাইলগুলি সম্পাদনা করে হিপ সাইজ বাড়ান। প্রাসঙ্গিক এন্ট্রিগুলি দেখতে এরকম:

• - X mx1000m (হিপ আকারের জন্য বরাদ্দকৃত সর্বোচ্চ মেমরি)
• - X ms64m (হিপ আকারের জন্য বরাদ্দকৃত সর্বনিম্ন মেমরির পরিমাণ)

sync-cmd.vmoptions এবং config-manager.vmoptions ফাইল উভয়ই সম্পাদনা করুন যাতে পরিবর্তনটি sync-cmd এবং কনফিগারেশন ম্যানেজার উভয় সংস্করণের ক্ষেত্রেই প্রযোজ্য হয়।

মেমোরির পরিমাণ বাড়ানোর জন্য - X mx সংখ্যাটি সম্পাদনা করুন। সংখ্যার পরে "m" নির্দেশ করে যে মেমোরিটি মেগাবাইট (MB) তে পরিমাপ করা হয়েছে। সঠিক পরিমাণ মেমোরি GCDS সার্ভারে কতটা আছে এবং সিঙ্ক্রোনাইজেশনের জন্য কতটা প্রয়োজন তার উপর নির্ভর করে। সঠিক আকার সেট করার জন্য আপনাকে সংখ্যাটি বেশ কয়েকবার সংশোধন করতে হতে পারে। GCDS চালানোর জন্য প্রয়োজনীয় বিনামূল্যের RAM এর পরিমাণ সম্পর্কে আরও তথ্যের জন্য, GCDS এর জন্য সিস্টেমের প্রয়োজনীয়তাগুলিতে যান।

ক্যাশে বন্ধ থাকা অবস্থায় GCDS কেন বারবার ত্রুটি ফেরত দেয়?

সমস্যাটি কোনও কনফিগারেশন সমস্যার কারণে হতে পারে, যেমন একটি এক্সক্লুশন রুলের ভুল কনফিগারেশন। এই ধরণের ভুল কনফিগারেশন GCDS ক্যাশিং দ্বারা লুকানো যেতে পারে।

GCDS আপনার Google পরিষেবার (যেমন Google Workspace বা Cloud Identity) জন্য সর্বাধিক ৮ দিনের জন্য ডেটা ক্যাশে সংরক্ষণ করে। ক্যাশে করা ডেটার আকারের উপর নির্ভর করে GCDS আরও ঘন ঘন ক্যাশে সাফ করতে পারে। তবে, যদি ক্যাশে সাফ না করা হয়, তাহলে আপনি ৮ দিন পর্যন্ত আপনার আপডেটগুলি দেখতে নাও পেতে পারেন।

উদাহরণস্বরূপ, আপনি আপনার LDAP ডেটা সিঙ্ক করেন এবং আপনার Google পরিষেবার জন্য একটি নতুন গ্রুপ তৈরি করেন (যেমন Google Workspace বা Cloud Identity)। এরপর আপনি পরবর্তী সিঙ্ক থেকে সেই গ্রুপটিকে বাদ দেওয়ার জন্য একটি এক্সক্লুশন নিয়ম তৈরি করেন। এক্সক্লুশন নিয়মটি ভুলভাবে কনফিগার করা হয়েছে এবং এটি ব্যর্থ হবে। তবে, পরবর্তী সিঙ্ক ক্যাশেড ডেটাতে কল করে এবং গ্রুপটি আপনার Google পরিষেবাতে থেকে যায়। যখন আপনি আবার ক্যাশ পরিষ্কার করে সিঙ্ক করেন, তখন ভুল কনফিগারেশনের কারণে গ্রুপটি আপনার Google পরিষেবা থেকে সরে যায়।

ম্যানুয়ালি ক্যাশে সাফ করতে:

• কনফিগারেশন ম্যানেজার থেকে একটি সিঙ্ক চালান এবং সিঙ্ক করার সময় ক্যাশে সাফ করার বিকল্পটি নির্বাচন করুন।
• কমান্ড থেকে একটি সিঙ্ক চালান এবং ক্যাশে জোর করে ফ্লাশ করতে -f আর্গুমেন্ট ব্যবহার করুন।
• xml কনফিগারেশন ফাইলটি পরিবর্তন করে maxCacheLifetime মান 0 তে সেট করুন।

গুরুত্বপূর্ণ : জোর করে ক্যাশে ফ্লাশ করলে সিঙ্ক্রোনাইজেশনের সময় নাটকীয়ভাবে বেড়ে যেতে পারে।

কেন GCDS ইতিমধ্যেই বিদ্যমান Google ব্যবহারকারী তৈরি করার চেষ্টা করছে?

যদি আপনি "409: ​​Entity already exists" ত্রুটিটি পান, তাহলে GCDS ইতিমধ্যেই বিদ্যমান Google ব্যবহারকারী তৈরি করার চেষ্টা করছে। যদি আপনি পরবর্তী সিঙ্কগুলিতে ত্রুটিটি দেখতে না পান, তাহলে সম্ভবত GCDS ক্যাশেটি পুরানো ছিল এবং ত্রুটিটি উপেক্ষা করা নিরাপদ।

যদি সমস্যাটি প্রতি সিঙ্কে বা প্রতি কয়েক দিন অন্তর ঘটে, তাহলে সবচেয়ে সম্ভাব্য কারণগুলি হল:

• গুগল ব্যবহারকারীদের বাদ দেওয়ার নিয়মটি অনেক বিস্তৃত—এই নিয়মটি LDAP ডিরেক্টরিতে থাকা কিছু গুগল ব্যবহারকারীর সাথে মিলে যায়।
• একটি কোয়েরি খুবই সংকীর্ণ—কোয়েরিটি LDAP ডিরেক্টরিতে থাকা কিছু Google ব্যবহারকারীর সাথে মেলে না।

উভয় পরিস্থিতিতেই GCDS ইতিমধ্যেই বিদ্যমান Google ব্যবহারকারীদের উপেক্ষা করতে পারে। যদি LDAP ব্যবহারকারী অনুসন্ধান নিয়মের ফলাফলে সেই ব্যবহারকারীরা বিদ্যমান থাকে, তাহলে GCDS আপনার Google অ্যাকাউন্টে সেগুলি তৈরি করার চেষ্টা করে।

সমস্যা সমাধানের জন্য, এক্সক্লুশন রুল বা সার্চ কোয়েরি সামঞ্জস্য করুন। অথবা, যদি আপনি চান যে GCDS আপনার LDAP ডিরেক্টরিতে থাকা ব্যবহারকারীদের সম্পূর্ণরূপে উপেক্ষা করুক, তাহলে আপনার LDAP ইউজার সার্চ রুল সামঞ্জস্য করুন অথবা একটি LDAP ইউজার এক্সক্লুশন রুল তৈরি করুন। বিস্তারিত জানার জন্য, এক্সক্লুশন রুলস এবং কোয়েরি সহ ডেটা বাদ দিন বিভাগে যান।

কেন কিছু ব্যবহারকারীকে গ্রুপ সদস্য হিসেবে সিঙ্ক করা হয় না?

যেকোনো ব্যবহারকারী অনুসন্ধান নিয়মের ফলাফল থেকে গ্রুপ সদস্যদের আলাদাভাবে সিঙ্ক্রোনাইজ করতে, GCDS ডিফল্টরূপে INDEPENDENT_GROUP_SYNC চালু করে। যদি আপনি গ্রুপ সিঙ্ক্রোনাইজেশনের জন্য সদস্য-রেফারেন্স বৈশিষ্ট্য ব্যবহার করেন, তাহলে GCDS LDAP ডিরেক্টরিতে থাকা প্রতিটি ব্যবহারকারীর ইমেল ঠিকানা সমাধান করার চেষ্টা করে, যেকোনো ব্যবহারকারী অনুসন্ধান নিয়ম নির্বিশেষে।

শুধুমাত্র ব্যবহারকারী অনুসন্ধান নিয়মের ফলাফলের উপর ভিত্তি করে গ্রুপ সদস্যদের সিঙ্ক্রোনাইজ করতে, আপনার কনফিগারেশন XML ফাইল থেকে INDEPENDENT_GROUP_SYNC সরিয়ে ফেলুন। GCDS:

• গ্রুপ সদস্যপদ সমাধানের জন্য ব্যবহারকারী অনুসন্ধানের নিয়মের ফলাফল ব্যবহার করে।
• শুধুমাত্র আপনার ব্যবহারকারীর সিঙ্কে অন্তর্ভুক্ত ব্যবহারকারীদের গ্রুপ সদস্য হিসাবে সিঙ্ক করে
• সাধারণ সেটিংসে ব্যবহারকারীর অ্যাকাউন্ট সিঙ্ক বন্ধ করলেও, ব্যবহারকারী অনুসন্ধানের নিয়মগুলি কার্যকর করে।

  (তবে, ফলাফলগুলি ব্যবহারকারী হিসেবে গুগলের সাথে সিঙ্ক হয় না বরং গ্রুপ সদস্য হিসেবে সিঙ্ক হয়, যদি যোগ্য ব্যবহারকারীরাও গ্রুপ সদস্য হিসেবে যোগ্য হন।)

সাধারণত, আপনি আপনার সিঙ্কটি এভাবে চালাতে চান না, বিশেষ করে যদি আপনি শেয়ার করা পরিচিতিগুলি সিঙ্ক করেন এবং আপনার গ্রুপ সদস্যরা পরিচিতি। এই ক্ষেত্রে, পরিচিতিগুলি গ্রুপ সদস্য হিসাবে সিঙ্ক্রোনাইজ হবে না।

কেন প্রতিটি সিঙ্কের সাথে কিছু ব্যবহারকারী বা গোষ্ঠী পুনরায় তৈরি করা হচ্ছে?

এই সমস্যাটি তখন ঘটে যখন গ্রুপ নেম অ্যাট্রিবিউট হিসেবে কনফিগার করা LDAP অ্যাট্রিবিউটে একটি সম্পূর্ণ ইমেল ঠিকানা থাকে না। এই সমস্যা সমাধানের জন্য, আপনার গ্রুপ অনুসন্ধানের নিয়মগুলি পরীক্ষা করুন এবং নিশ্চিত করুন যে GCDS গ্রুপের নামের জন্য একটি সম্পূর্ণ ইমেল ঠিকানা ব্যবহার করে। নিম্নলিখিত পদ্ধতিগুলির মধ্যে একটি ব্যবহার করুন:

• গ্রুপ নেম অ্যাট্রিবিউটকে একটি ভিন্ন LDAP অ্যাট্রিবিউটে সেট করুন যা প্রতিটি গ্রুপের জন্য একটি সম্পূর্ণ ইমেল ঠিকানা নির্দিষ্ট করে, যেমন মেইল।
• গুগল ডোমেন সেটিংসে "LDAP ইমেল ঠিকানায় ডোমেন নাম প্রতিস্থাপন করুন" চালু করুন, যাতে আপনার গ্রুপ নেম অ্যাট্রিবিউট গুগল-সাইড গ্রুপ নামের সাথে মিলে যায়।
• আপনার গ্রুপ অনুসন্ধান নিয়মে একটি গ্রুপ নাম প্রত্যয় উল্লেখ করে গ্রুপ নামের সাথে ডোমেন নাম যুক্ত করুন।

অ্যাক্টিভ ডিরেক্টরিতে ১,৫০০ এরও বেশি সদস্যের গ্রুপগুলি সঠিকভাবে সিঙ্ক হচ্ছে না

LDAP কনফিগারেশন বিভাগের সার্ভার টাইপ ক্ষেত্রে আপনি MS Active Directory নির্বাচন করেছেন কিনা তা নিশ্চিত করুন।

"LDAP ইমেল ঠিকানাগুলিতে ডোমেন নাম প্রতিস্থাপন করুন" কীভাবে ব্যবহার করব?

এই বিকল্পটি (XML ফাইলে SUPPRESS_DOMAIN হিসাবে দেখানো হয়েছে) ব্যবহার করা হয় যদি LDAP ডিরেক্টরিতে থাকা ইমেল ঠিকানাগুলি আপনার Google ডোমেনের চেয়ে আলাদা ডোমেনে থাকে। যখন আপনি এটি চালু করেন, তখন GCDS ডোমেনের অংশটি সমস্ত ইমেল ঠিকানা থেকে বাদ দেয়।

যেকোনো প্রক্রিয়াকরণ ডোমেন নাম ছাড়াই করা হয়। যদি আপনি ইমেল ঠিকানার উপর ভিত্তি করে বর্জন নিয়ম ব্যবহার করেন, তাহলে বর্জন নিয়মের জন্য আপনাকে কেবল ইমেল ঠিকানার স্থানীয় অংশ বিবেচনা করতে হবে।

উদাহরণস্বরূপ, যদি আপনার LDAP ইমেল ঠিকানায় ডোমেন নাম প্রতিস্থাপন বন্ধ থাকে এবং আপনি একটি Exact Match বর্জন নিয়ম তৈরি করেন, তাহলে ব্যবহারকারীর ইমেল ঠিকানা হিসাবে luka@example.com লিখুন যাতে মিলবে। যদি আপনি LDAP ইমেল ঠিকানায় ডোমেন নাম প্রতিস্থাপন চালু করে থাকেন, তাহলে luka ব্যবহার করুন। luka@example.com মেলানোর চেষ্টা করা কাজ করবে না, কারণ তুলনা করার আগে @example.com বাদ দেওয়া হয়েছে।

আমি কি স্ট্যাটিক এবং ডাইনামিক গ্রুপ নেস্ট করতে পারি?

GCDS ব্যবহার করে গ্রুপ প্রভিশন করার সময়, আপনি স্ট্যাটিক গ্রুপের নীচে (অথবা ডায়নামিক গ্রুপের নীচে) ডাইনামিক গ্রুপ নেস্ট করতে পারবেন না। GCDS-এর জন্য স্ট্যাটিক গ্রুপগুলিকে ডায়নামিক গ্রুপ থেকে আলাদাভাবে জিজ্ঞাসা করতে হবে; তবে সমস্ত নেস্টেড গ্রুপকে একই কোয়েরির অংশ হতে হবে।

ডাইনামিক গ্রুপগুলিকে স্ট্যাটিক গ্রুপ হিসেবে বাস্তবায়নের একটি উপায় খুঁজে বের করুন, সম্ভবত এমন একটি কাজ স্বয়ংক্রিয় করে যা পর্যায়ক্রমে প্রতিটি ডাইনামিক গ্রুপকে ডিরেক্টরিতে স্ট্যাটিক গ্রুপ তৈরি করার জন্য জিজ্ঞাসা করে। GCDS এরপর স্ট্যাটিক গ্রুপগুলিকে (যেমন ডায়নামিক গ্রুপ থেকে তৈরি) প্রভিশনিংয়ের জন্য ব্যবহার করতে পারে এবং ডায়নামিক গ্রুপকে প্রভিশন করার জন্য নয়।

আমার LDAP কোয়েরি থেকে কেন আমি অপ্রত্যাশিত ফলাফল পেলাম?

LDAP কোয়েরির ফলাফল কনফিগারেশন ম্যানেজার সেটিংস এবং LDAP সার্ভারের উপর নির্ভর করে। যদি আপনার LDAP অনুসন্ধান নিয়ম অপ্রত্যাশিত ফলাফল দেয় তবে এই সমস্যা সমাধানের টিপসগুলি ব্যবহার করুন। নিশ্চিত করুন:

• কনফিগারেশন ম্যানেজারে LDAP কোয়েরি সঠিকভাবে সেট আপ করা হয়েছে — যখন আপনি একটি অনুসন্ধান নিয়ম সেট আপ করেন, যাচাই করতে Test LDAP কোয়েরি ক্লিক করুন। বিস্তারিত জানার জন্য, ডেটা সিঙ্ক্রোনাইজ করতে LDAP অনুসন্ধান নিয়ম ব্যবহার করুন এ যান।
• একাধিক কোয়েরি একে অপরের সাথে সাংঘর্ষিক নয় — আপনি এমন কোনও অনুসন্ধান বা বর্জন নিয়ম সেট আপ করেননি যা কোয়েরির ফলাফল পরিবর্তন করে।
• LDAP সার্ভারের জন্য অনুমোদিত ব্যবহারকারীর পর্যাপ্ত অনুমতি আছে — নিশ্চিত করুন যে LDAP সার্ভারটি প্রমাণীকরণের জন্য ব্যবহৃত প্রশাসক একই সার্ভারে কমান্ড লাইন ব্যবহার করতে পারেন। LDAP সার্ভারে কোয়েরিটি চেষ্টা করুন এবং ফলাফল যাচাই করুন।

গ্রুপ তৈরি করা যায়নি ত্রুটি

আপনি "Group ... could not be created" ত্রুটি বার্তাটি দেখতে পেতে পারেন। বার্তা: GCDS লগে এই রিসোর্স/এপিআই অ্যাক্সেস করার জন্য অনুমোদিত নয় ।

সমস্যা সমাধানের জন্য, ব্যবহারকারী এবং গ্রুপ ইমেল ঠিকানার জন্য ডোমেন ধারণকারী অ্যাক্টিভ ডিরেক্টরি (AD) অ্যাট্রিবিউটটি আপনার সুপার অ্যাডমিন অ্যাকাউন্ট ব্যবহার করে এমন ডোমেনের সাথে মেলে কিনা তা পরীক্ষা করুন।

GCDS এর সাথে সিঙ্ক করার পর আমার ডোমেন ডিরেক্টরিতে কেন আমি ডুপ্লিকেট পরিচিতি দেখতে পাই?

এই সমস্যাটি সাধারণত তখন ঘটে যখন আপনি শেয়ার করা পরিচিতিগুলি সিঙ্ক করেন এবং অনুসন্ধানের নিয়মগুলি ভুলভাবে তৈরি করা হয়।

GCDS-এর সাথে আপনি 2 ধরণের প্রাসঙ্গিক বস্তু সিঙ্ক করতে পারেন:

• ব্যবহারকারীর প্রোফাইল — আপনার গুগল ডোমেনের ব্যবহারকারীরা যাদের অতিরিক্ত ডেটা যেমন ফোন নম্বর বা ঠিকানা রয়েছে। আপনি শুধুমাত্র আপনার ডোমেনে বিদ্যমান ব্যবহারকারীর জন্য একটি প্রোফাইল সিঙ্ক করতে পারেন।
• শেয়ার করা পরিচিতি — আপনার ডোমেনের ব্যবহারকারীদের সাথে যোগাযোগ করতে হবে এমন বহিরাগত পক্ষের পরিচিতি।

এই সমস্যা সমাধানের জন্য, আপনার নিজস্ব ডোমেনের ব্যবহারকারীদের বাদ দিতে আপনার শেয়ার করা পরিচিতি অনুসন্ধানের নিয়মগুলি সংশোধন করুন। পরবর্তী সিঙ্কে, GCDS অপ্রয়োজনীয় পরিচিতিগুলি মুছে ফেলার চেষ্টা করে। প্রথম সিঙ্কের জন্য আপনাকে শেয়ার করা পরিচিতি মুছে ফেলার সীমা সামঞ্জস্য করতে হতে পারে।

কিছু ব্যবহারকারী গুগল ক্যালেন্ডারে তাদের প্রধান কর্মস্থল দেখতে পান না কেন?

কিছু পরিস্থিতিতে, ব্যবহারকারীরা মিটিং শিডিউল বা আয়োজনের সময় Google ক্যালেন্ডারে তাদের প্রধান কর্মস্থল দেখতে পান না।

যদি আপনি এই সমস্যাটি দেখতে পান, তাহলে নিশ্চিত করুন যে অবস্থানের ধরণ এবং এলাকার বৈশিষ্ট্যগুলি "ডেস্ক" তে সেট করা আছে।

কেন একটি অনুসন্ধান নিয়ম কিছু খুঁজে পাচ্ছে না?

যদি আপনার অনুসন্ধানের ফলাফলে সমস্যা হয়, তাহলে দেখুন:

• নিয়মের সুযোগ। আপনাকে সুযোগটি Sub-tree তে সেট করতে হতে পারে।
• আপনি যে অনুসন্ধান নিয়মটি ব্যবহার করছেন তা সঠিক।
• ব্যবহৃত বৈশিষ্ট্যগুলি বিদ্যমান এবং দৃশ্যমান।

আপনার LDAP কোয়েরি। যাচাই করুন যে আপনার LDAP সার্ভারের কোয়েরিটি GCDS-এ কনফিগার করা একই অ্যাডমিন ব্যবহারকারীর নাম ব্যবহার করছে।

আরও বিস্তারিত জানার জন্য, ডেটা সিঙ্ক্রোনাইজ করার জন্য LDAP অনুসন্ধানের নিয়ম ব্যবহার করুন -এ যান।

ব্যতিক্রম নিয়ম তৈরি করার সময়, আমি কেন ঠিক আছে বোতামটি দেখতে পাচ্ছি না?

আপনি হয়তো এমন একটি ফন্ট ব্যবহার করছেন যা স্ক্রিনের জন্য খুব বড়। ডায়ালগ বক্সটি বড় বা অতিরিক্ত বড় ফন্টের সাথে কাজ করে না। আপনার ফন্টের আকার পরিবর্তন করুন অথবা সরাসরি আপনার XML ফাইল সম্পাদনা করুন।