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

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

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

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

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

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

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
   হ্যান্ডলার = 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 সিঙ্ক চালান (লগিং ' ট্রেস' এ সেট করে)।

   gcdshttp*.log নামের লগ ফাইলগুলো লিনাক্সের হোমডির (homedir) বা মাইক্রোসফট উইন্ডোজের প্রোফাইল ফোল্ডারে (profile folder) তৈরি হয়। এই ফাইলগুলো একসাথে আর্কাইভ করে রাখুন, কারণ এগুলো বেশ বড় হতে পারে।

7. ভবিষ্যতে বড় আকারের লগ ফাইল তৈরি হওয়া রোধ করতে ধাপ ৪-এ যোগ করা লাইনগুলো মুছে ফেলুন।
8. সহায়তার জন্য নিম্নলিখিত ফাইলগুলি প্রদান করুন:
   • এক্সএমএল ফাইল
   • সর্বশেষ সিঙ্ক থেকে প্রাপ্ত ট্রেস-লেভেল লগ এবং gcdshttp*.log ফাইলগুলো

পরামর্শ: আপনি যদি কোনো নতুন ক্লাসের জন্য লগিং চালু করতে চান, তাহলে class.fqdn.level = ALL এই ফর্মে একটি লাইন যোগ করুন, পুরো সেটআপ ব্লকটি নকল করার কোনো প্রয়োজন নেই।

লগ করা অনুরোধ এবং প্রতিক্রিয়ার প্রতিটি বডির আকার ১৬ কিলোবাইটে সীমাবদ্ধ। যদি আপনি দেখেন যে এই সীমা অতিক্রম করার কারণে কোনো লগ এন্ট্রি সংক্ষিপ্ত হয়ে গেছে, তাহলে ফিডলারের মতো একটি ডিবাগিং প্রক্সি ব্যবহার করুন।

ফিডলার সক্রিয় করতে, এই ধাপগুলো অনুসরণ করুন:

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

আপনি যদি লিনাক্সে GCDS ব্যবহার করেন, তাহলে আপনি উইন্ডোজের বিশ্বস্ত সার্টিফিকেট স্টোর ব্যবহার করতে পারবেন না, তাই আপনাকে ফিডলার রুট সার্টিফিকেটটি GCDS-এর জাভা ট্রাস্ট স্টোরে ইম্পোর্ট করতে হবে। এই ধাপগুলো সম্পর্কে বিস্তারিত জানতে, সার্টিফিকেট-সম্পর্কিত সমস্যা সমাধান (Troubleshoot certificate-related problems ) অংশে যান।

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

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

আপনার নোটিফিকেশনের জন্য 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 ফাইল, অথবা একই মেশিনে ভিন্ন ব্যবহারকারী হিসেবে কীভাবে সেটি খুলতে হয়, তার নির্দেশাবলীর জন্য ‘কনফিগারেশন ফাইল নিয়ে কাজ’ দেখুন।

যদি 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
• বন্দর: ৬৩৬
• প্রোটোকল: এলডিএপি+এসএসএল
• প্রমাণীকরণ ব্যবহারকারী ডিএন: cn=GCDS,ou=Users,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-এর মতো কোনো গ্লোবাল ক্যাটালগ পোর্ট ব্যবহার করেন, তাহলে অ্যাট্রিবিউটটি গ্লোবাল ক্যাটালগে প্রতিলিপি নাও হতে পারে।

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

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

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

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

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

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

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

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

1. অ্যাডমিন এসডিকে এপিআই রেফারেন্স ওভারভিউ- তে যান।
2. বাম দিকে, ডিরেক্টরি এপিআই (Directory API)- তে ক্লিক করুন, তারপর, রেস্ট রিসোর্স (REST Resources)-এর জন্য, আপনি যে রেস্ট রিসোর্সটি কোয়েরি করতে চান সেখানে যান।
3. ডানদিকে, আপনি যে পদ্ধতিটি চেষ্টা করতে চান সেটিতে ক্লিক করুন এবং 'Try it'-এ ক্লিক করুন।

   যদি এপিআই রেফারেন্স পেজে ‘Try it’ না দেখায়, তাহলে অপশন ২-এ যান: OAuth 2.0 প্লেগ্রাউন্ড ব্যবহার করুন।

4. GCDS-কে অনুমোদন দিতে আপনি যে অ্যাডমিন ক্রেডেনশিয়াল ব্যবহার করেছিলেন, তা প্রবেশ করান।

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

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

বিকল্প ২: OAuth 2.0 প্লেগ্রাউন্ড ব্যবহার করুন

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

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

5. টোকেনগুলির জন্য বিনিময় অনুমোদন কোডে ক্লিক করুন।

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

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

   পরামর্শ : আপনি বেশিরভাগ তথ্য এপিআই মেথড রেফারেন্স ওয়েবপেজে খুঁজে পেতে পারেন।

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

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

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

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

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

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

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

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

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

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

ম্যানুয়ালি ক্যাশ পরিষ্কার করতে:

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

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

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

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

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

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

সমস্যাটি সমাধান করতে, এক্সক্লুশন রুল বা সার্চ কোয়েরিটি অ্যাডজাস্ট করুন। অথবা, যদি আপনি চান যে GCDS আপনার LDAP ডিরেক্টরিতে থাকা ইউজারদের সম্পূর্ণ উপেক্ষা করুক, তাহলে আপনার LDAP ইউজার সার্চ রুলটি অ্যাডজাস্ট করুন বা একটি LDAP ইউজার এক্সক্লুশন রুল তৈরি করুন। বিস্তারিত জানতে, ‘Omit data with exclusion rules & queries’ অংশে যান।

কখনও কখনও আপনার কাস্টম স্কিমা অ্যাট্রিবিউটগুলো, বিশেষ করে নতুন তৈরি করা অ্যাট্রিবিউটগুলো, আপনার LDAP ডিরেক্টরি থেকে গুগল ব্যবহারকারীদের কাছে সিঙ্ক নাও হতে পারে। এমনটা হলে, সফলভাবে সিঙ্ক হওয়ার পরেও আপনার গুগল ব্যবহারকারীদের অ্যাট্রিবিউট ফিল্ডগুলো খালি থেকে যায়।

সম্ভাব্য কারণগুলোর মধ্যে রয়েছে:

• Google Cloud Directory Sync (GCDS)-এ কনফিগার করা LDAP সার্ভারের অনুমোদিত ব্যবহারকারীর আপনার LDAP ডিরেক্টরির ওই নির্দিষ্ট অ্যাট্রিবিউটগুলোতে রিড অ্যাক্সেস নেই।
• আপনি যদি গ্লোবাল ক্যাটালগ সার্ভার (পোর্ট ৩২৬৮ বা ৩২৬৯) ব্যবহার করেন এবং অ্যাক্টিভ ডিরেক্টরি স্কিমা থেকে ‘Replicate this attribute to the Global Catalog’ বক্সটি চেক না করে থাকেন, তাহলে সিঙ্কের সময় আপনার কাস্টম স্কিমা অ্যাট্রিবিউটগুলো গুগল ক্লাউড সার্ভারে খুঁজে পাওয়া যাবে না।

আপনার কাস্টম স্কিমা অ্যাট্রিবিউটগুলো সিঙ্ক হচ্ছে কিনা তা নিশ্চিত করতে, নিচের ধাপগুলো অনুসরণ করুন:

1. আপনার LDAP অ্যাডমিনিস্ট্রেটরের সাথে কাজ করে নিশ্চিত করুন যে, LDAP অথেনটিকেশনের জন্য GCDS-এ কনফিগার করা ব্যবহারকারীর, সিঙ্ক হতে ব্যর্থ হওয়া সমস্ত অ্যাট্রিবিউটে রিড অ্যাক্সেস রয়েছে।
2. যে মেশিনে GCDS চলছে, সেই একই মেশিন ব্যবহার করে একটি LDAP ব্রাউজারের মাধ্যমে আপনার LDAP সার্ভারে সংযোগ করুন। সংযোগ করার সময়, GCDS যে ব্যবহারকারীকে ব্যবহার করে, সেই একই ব্যবহারকারী দিয়ে প্রমাণীকরণ নিশ্চিত করুন। প্রভাবিত ব্যবহারকারীদের মধ্যে একজনকে খুঁজুন এবং পরীক্ষা করে দেখুন যে আপনি সেই অ্যাট্রিবিউটগুলোর মান দেখতে পাচ্ছেন কি না, যেগুলো সিঙ্ক হচ্ছে না।
3. অনুমতিগুলো সঠিক আছে কিনা তা নিশ্চিত করার পর, GCDS ক্যাশে পরিষ্কার করুন এবং একটি সিঙ্ক চালান।

যদি আপনার কাস্টম স্কিমা অ্যাট্রিবিউটগুলো তারপরও সিঙ্ক না হয়, তাহলে আপনার GCDS তথ্য সংগ্রহ করুন এবং সাপোর্টে যোগাযোগ করুন। বিস্তারিত জানতে, “সাপোর্টে যোগাযোগ করার আগে আমার কী কী GCDS তথ্য প্রয়োজন?” অংশে যান।

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

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

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

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

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

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

• গ্রুপ নেম অ্যাট্রিবিউটটিকে একটি ভিন্ন LDAP অ্যাট্রিবিউটে সেট করুন যা প্রতিটি গ্রুপের জন্য একটি সম্পূর্ণ ইমেল ঠিকানা নির্দিষ্ট করে, যেমন মেইল।
• Google Domain Settings-এ LDAP ইমেল অ্যাড্রেসে ডোমেইন নাম প্রতিস্থাপন (Replace domain names in LDAP email addresses) বিকল্পটি চালু করুন, যাতে আপনার Group Name Attribute-টি Google-এর গ্রুপ নামগুলোর সাথে মিলে যায়।
• আপনার গ্রুপ সার্চ রুলে একটি গ্রুপ নেম সাফিক্স উল্লেখ করে গ্রুপ নেমের সাথে ডোমেইন নেম যোগ করুন।

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

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

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

উদাহরণস্বরূপ, যদি আপনার ‘Replace domain names in LDAP email addresses’ অপশনটি বন্ধ করা থাকে এবং আপনি একটি ‘Exact Match’ এক্সক্লুশন রুল তৈরি করেন, তাহলে ম্যাচ করার জন্য ব্যবহারকারীর ইমেল অ্যাড্রেস হিসেবে luka@example.com লিখুন। যদি আপনার ‘Replace domain names in LDAP email addresses’ অপশনটি চালু করা থাকে, তাহলে luka ব্যবহার করুন। luka@example.com ম্যাচ করার চেষ্টা করলে তা কাজ করবে না, কারণ তুলনা করার আগে @example.com অংশটি বাদ দেওয়া হয়।

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

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

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

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

আপনি GCDS লগ-এ " Group ... could not be created . Message: Not Authorized to access this resource/api" এই ত্রুটি বার্তাটি দেখতে পারেন।

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

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

দুই ধরনের প্রাসঙ্গিক অবজেক্ট আছে যা আপনি GCDS-এর সাথে সিঙ্ক করতে পারেন:

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

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

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

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

অনুসন্ধানের ফলাফল নিয়ে সমস্যা হলে, যাচাই করুন:

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

আরও বিস্তারিত জানতে, "ডেটা সিঙ্ক্রোনাইজ করতে LDAP সার্চ নিয়ম ব্যবহার করুন" অংশে যান।

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

যদি আপনার সার্চ শুধুমাত্র ১,০০০ উপলব্ধ ব্যবহারকারীকে (বা ডিফল্ট LDAP পেজ সাইজ) ইম্পোর্ট করে, তাহলে কনফিগারেশন ম্যানেজারের LDAP হোস্ট নেম সেটিংটি একটি জেনেরিক বা ফরেস্ট রুট ডোমেইনে সেট করা থাকতে পারে, যা আপনার বেস DN-এর অবজেক্টগুলোর জন্য রেফারেল ইস্যু করে।

এই সমস্যাটি সমাধান করতে, কনফিগারেশন ম্যানেজার আপডেট করুন যাতে হোস্ট নেম সেটিংটি বেস ডিএন সেটিং-এর সাথে মিলে যায়। অথবা, এমন একটি ডোমেইন কন্ট্রোলার (উদাহরণস্বরূপ, dc01.example.com) ব্যবহার করুন যার বেস ডিএন-এ ইউজার অ্যাকাউন্ট অবজেক্টগুলো রয়েছে।