ข้อมูลต่อไปนี้เป็นวิธีแก้ปัญหาที่คุณอาจพบขณะกำหนดค่า Google Cloud Directory Sync (GCDS)
การตั้งค่าและการกำหนดค่า | การจำลองและการซิงค์ | ข้อผิดพลาด | ผู้ใช้และกลุ่ม | รายชื่อติดต่อและปฏิทิน | กฎ
ลองใช้เครื่องมือวิเคราะห์บันทึก
เครื่องมือนี้จะตรวจพบปัญหาส่วนใหญ่ได้โดยใช้เวลาไม่นานหลังการส่ง
- ส่งบันทึกการติดตามของคุณ (ในรูปแบบไฟล์ที่ไม่ได้บีบอัดหรือไฟล์ ZIP) ไปที่เครื่องมือวิเคราะห์บันทึกกล่องเครื่องมือของ Google Admin
- ส่งไฟล์ที่ไม่ได้บีบอัดไปที่เครื่องมือวิเคราะห์บันทึก 2 เพื่อทำการวิเคราะห์บันทึกแบบขั้นสูง
โปรดดูรายละเอียดเกี่ยวกับวิธีเปิดใช้การบันทึกระดับการติดตาม
การตั้งค่าและการกำหนดค่า
เปิดส่วน | ยุบทั้งหมดและกลับไปด้านบนสุด
แก้ปัญหาการกำหนดค่าโดยใช้เครื่องมือจัดการการกำหนดค่าถ้าคุณพบว่าการซิงค์ข้อมูลมีปัญหา โปรดตรวจสอบว่าได้กำหนดค่าในเครื่องมือจัดการการกำหนดค่าไว้อย่างถูกต้องแล้วดูว่าการทดสอบใดที่ดำเนินการไม่สำเร็จ โดยทำตามขั้นตอนดังนี้
- เปิดไฟล์ XML ที่ใช้กำหนดค่าการซิงค์ข้อมูลในเครื่องมือจัดการการกำหนดค่า
- คลิกทดสอบการเชื่อมต่อในหน้าการเชื่อมต่อ LDAP เพื่อตรวจสอบว่าเชื่อมต่อกับเซิร์ฟเวอร์ LDAP ได้
- คลิกทดสอบการแจ้งเตือนในหน้าการแจ้งเตือนเพื่อยืนยันว่าคุณส่งการแจ้งเตือนการทดสอบได้
- คลิกจำลองการซิงค์ในหน้าซิงค์เพื่อยืนยันว่าคุณป้อนข้อมูลในฟิลด์ที่จำเป็นทั้งหมดแล้วและเพื่อยืนยันว่าการซิงค์ทำงาน
ในบางกรณีที่พบไม่บ่อยนัก ทีมสนับสนุนของ Google Cloud อาจขอให้คุณเปิดใช้การบันทึก HTTP อย่างสมบูรณ์ นอกเหนือจากการเปิดใช้การบันทึกที่ระดับการติดตามใน GCDS ทั้งนี้การบันทึก HTTP อย่างสมบูรณ์จะใช้เพื่อดูคำขอ API โดยเฉพาะซึ่งสร้างโดย GCDS และการตอบกลับโดย API ของ Google
สำคัญ: บันทึก HTTP เต็มรูปแบบอาจมีข้อมูลที่ละเอียดอ่อนอย่างมาก โปรดนำข้อมูลละเอียดอ่อนใดๆ (เช่น ฟิลด์ข้อมูล refresh_token หรือ access_token ปัจจุบัน) ออกก่อนที่จะส่งบันทึกให้ทีมสนับสนุน
วิธีเปิดการบันทึก HTTP อย่างเต็มรูปแบบ
- ตรวจสอบว่า sync-cmd หรือเครื่องมือจัดการการกำหนดค่าไม่ได้กำลังเรียกใช้งาน GCDS อยู่
- ไปที่โฟลเดอร์การติดตั้ง GCDS
-
แก้ไขไฟล์ jre/lib/logging.properties
- เพิ่มบรรทัดต่อไปนี้ที่ส่วนท้ายของไฟล์
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 - บันทึกไฟล์
- ซิงค์ GCDS อีกครั้ง (โดยตั้งค่าการบันทึกเป็นแบบติดตาม)
ระบบจะสร้างไฟล์บันทึกชื่อ gcdshttp*.log ไว้ใน homedir (Linux) หรือโฟลเดอร์โปรไฟล์ (Microsoft Windows) โปรดเก็บไฟล์เหล่านี้ไว้ด้วยกันเนื่องจากไฟล์อาจมีขนาดค่อนข้างใหญ่
- ลบบรรทัดที่เพิ่มไว้ในขั้นตอนที่ 4 เพื่อไม่ให้ระบบสร้างไฟล์ขนาดใหญ่อีกในอนาคต
จากนั้นให้ส่งไฟล์ต่อไปนี้ไปยังทีมสนับสนุน
- ไฟล์ XML ที่ใช้
- ไฟล์บันทึกระดับการติดตามจากการซิงค์ล่าสุด
-
ไฟล์ gcdshttp*.log ที่ได้จากการซิงค์
ทีมสนับสนุนจะเห็นข้อมูลที่ Directory API ส่งไปยัง GCDS รวมทั้งการตอบกลับของ GCDS ได้จากบันทึกดังกล่าว
เนื้อหาคำขอและคำตอบที่บันทึกไว้จะมีขนาดได้ไม่เกินรายการละ 16 KB หากพบรายการบันทึกที่ถูกตัดทอนออกไปเนื่องจากมีขนาดเกินขีดจำกัดที่กำหนด ให้ใช้ Fiddler ตามที่แนะนำด้านล่าง
หมายเหตุ: หากต้องการใช้พร็อกซีการแก้ไขข้อบกพร่องอย่าง Fiddler ร่วมกับ GCDS คุณต้องอัปเดตไฟล์ .vmoptions เพื่อตั้งค่า GCDS ให้ใช้ที่เก็บใบรับรองที่เชื่อถือได้ของ Windows และปิดการตรวจสอบ CRL จากนั้นจึงตั้งค่า Fiddler ให้เป็นพร็อกซีเซิร์ฟเวอร์ใน GCDS (มักจะใช้เป็น 127.0.0.1 ในพอร์ต 8888) Fiddler จึงจะบันทึกการเชื่อมต่อได้ หากใช้ GCDS ใน Linux คุณจะไม่สามารถใช้ที่เก็บใบรับรองที่เชื่อถือได้ของ Windows ได้ คุณจึงต้องนำเข้าใบรับรองรูทของ Fiddler ไปยัง Java truststore ของ GCDS โปรดดูข้อมูลเพิ่มเติมที่หัวข้อนำเข้าใบรับรองเซิร์ฟเวอร์
โปรดดูวิธีเปิดไฟล์ XML ที่บันทึกไว้ในเครื่องอื่นหรือไฟล์ที่ผู้ใช้คนอื่นบันทึกลงในเครื่องเดียวกันที่หัวข้อใช้งานไฟล์การกำหนดค่า
หากข้อมูล LDAP ในบันทึกระดับการติดตามของ GCDS ไม่ตรงกับสิ่งที่คุณคาดหวังว่าจะเห็นในเซิร์ฟเวอร์ LDAP (เช่น ไม่พบผู้ใช้หรือแอตทริบิวต์ไม่มีค่าที่ถูกต้อง) ให้ส่งออกข้อมูลจาก ไดเรกทอรี LDAP ในรูปแบบ LDIF ฝ่ายสนับสนุนจะเปรียบเทียบข้อมูลดังกล่าวกับข้อมูล LDAP ได้จากบันทึกของ GCDS
เมื่อส่งออกข้อมูล ให้ใช้เครื่องมือ Query ของ LDAP เช่น ldapsearch (Linux) หรือ ldifde (Windows) และจําลองเงื่อนไขแบบเดียวกับที่ GCDS ใช้งาน โดยให้ทำดังนี้
- ใช้การตั้งค่าการเชื่อมต่อเดียวกับที่ GCDS กําหนดค่าไว้ใช้
- เรียกใช้เครื่องมือ Query จากเครื่องเดียวกับที่ GCDS ทำงานอยู่
- ใช้ชื่อผู้ใช้เดียวกันสําหรับการตรวจสอบสิทธิ์ LDAP ของ GCDS
ตัวอย่าง
บันทึก GCDS ไม่ได้แสดงแอตทริบิวต์ mail ของผู้ใช้ และการตั้งค่ากฎการค้นหาของ GCDS มีลักษณะดังนี้
- DN ฐาน: ou=Ireland,dc=altostrat,dc=com
- ขอบเขต: Subtree
- ตัวกรองการค้นหา: (&(objectCategory=person)(objectClass=user))
- เซิร์ฟเวอร์: dc01.altostrat.com
- พอร์ต: 636
- โปรโตคอล: LDAP+SSL
- 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ด้วยรหัสผ่านของผู้ใช้ LDAP ที่ตั้งไว้ใน GCDS)
หากเอาต์พุต (out.ldif) ไม่มีแอตทริบิวต์ mail สําหรับผู้ใช้ที่ได้รับผลกระทบ แสดงว่าโครงสร้างพื้นฐาน LDAP มีปัญหา ซึ่งอาจเกี่ยวข้องกับสิทธิ์ของผู้ใช้ที่คุณใช้เพื่อเข้าถึง LDAP (เช่น ทั้ง OpenLDAP และ Active Directory อนุญาตการกำหนดสิทธิ์ระดับแอตทริบิวต์) หรืออาจทําซ้ำแอตทริบิวต์ไปยังแคตตาล็อกส่วนกลาง หากคุณใช้พอร์ตแคตตาล็อกส่วนกลาง เช่น 3268 หรือ 3269
หากเอาต์พุตมีแอตทริบิวต์ mail สําหรับผู้ใช้ที่ได้รับผลกระทบ ให้ระบุรายละเอียดต่อไปนี้ให้ทีมสนับสนุนของ Google Workspace
- ไฟล์ out.ldif
- ภาพหน้าจอของ Command Prompt หรือหน้าต่างเทอร์มินัลที่คุณเรียกใช้คําสั่ง
(อย่าลืมนํารหัสผ่านออกก่อน) - บันทึกระดับการติดตามของ GCDS
การจำลองและการซิงค์
เปิดส่วน | ยุบทั้งหมดและกลับไปด้านบนสุด
ฉันต้องใช้เซิร์ฟเวอร์การแจ้งเตือนเพื่อจำลองการซิงค์ไหมหากต้องการจำลองการซิงค์ข้อมูล คุณต้องใช้เซิร์ฟเวอร์ที่ส่งอีเมลได้ หากต้องการใช้งาน GCDS ในเครื่องเซิร์ฟเวอร์อีเมล คุณจะใช้ที่อยู่ IP ของเซิร์ฟเวอร์อีเมลเป็น 127.0.0.1 หรือติดต่อผู้ดูแลระบบอีเมลเพื่อขอข้อมูลอีเมลที่ถูกต้องก็ได้
หากใช้บรรทัดคําสั่งเพื่อเรียกใช้การซิงค์และการซิงค์ไม่เริ่มขึ้น ให้ตรวจสอบว่าคุณใช้อาร์กิวเมนต์ -o หรือ --oneinstance ในบรรทัดคําสั่ง
หากคุณใช้อาร์กิวเมนต์ดังกล่าว GCDS จะสร้างไฟล์ LOCK (.lock) ที่เชื่อมโยงกับไฟล์การกำหนดค่า XML และหากพบไฟล์ LOCK อื่นในเซิร์ฟเวอร์เดียวกัน GCDS จะไม่เรียกใช้การซิงค์เพื่อป้องกันไม่ให้มีอินสแตนซ์หลายรายการของ GCDS ทำงานพร้อมกัน
หากไม่มีอินสแตนซ์อื่นๆ ของ GCDS ทำงานอยู่ ให้ตรวจหาไฟล์ LOCK อื่นในเซิร์ฟเวอร์ โปรดลบไฟล์ด้วยตนเอง แล้วลองเรียกใช้การซิงค์อีกครั้ง
หากการซิงค์ไม่สมบูรณ์ เช่น การเป็นสมาชิกแบบเต็มของกลุ่มไม่ซิงค์ แสดงว่า Directory API อาจมีปัญหา หากต้องการยืนยันว่าปัญหานี้เกี่ยวข้องกับ API แทนที่จะเป็นผลิตภัณฑ์ GCDS ให้เรียกใช้ Directory API ด้วยตนเองและตรวจสอบผลลัพธ์ หากต้องการเรียก API ด้วยตนเอง ให้เลือก 1 ใน 2 ตัวเลือกดังนี้
ตัวเลือกที่ 1: ใช้หน้าเอกสารอ้างอิง API
- ไปที่ภาพรวมเอกสารอ้างอิง API ของ Admin SDK
- ทางด้านซ้าย ให้คลิก Directory API สำหรับ REST Resources ให้ไปที่ REST Resource ที่ต้องการค้นหา
- ทางด้านขวา ให้คลิกเมธอดที่ต้องการลองใช้ แล้วคลิกลองเลย
หากหน้าเอกสารอ้างอิง API ไม่แสดงตัวเลือกลองใช้เลย ให้ไปที่ตัวเลือกที่ 2: ใช้ OAuth 2.0 Playground
- ป้อนข้อมูลเข้าสู่ระบบของผู้ดูแลระบบที่คุณใช้เพื่อให้สิทธิ์ GCDS
โปรดดูรายละเอียดที่หัวข้อกำหนดการตั้งค่าโดเมน Google
- ตรวจสอบข้อมูลเพื่อให้แน่ใจว่า API ตอบกลับตามที่คาดไว้
ตัวเลือกที่ 2: ใช้ OAuth 2.0 Playground
- เปิด OAuth 2.0 Playground
- เลือกตัวเลือกต่อไปนี้
- เลือกขอบเขตจากรายการ
- คัดลอกขอบเขตจากรายการขอบเขตการให้สิทธิ์ในหน้าเอกสารอ้างอิง API จากนั้นวางขอบเขตในช่องป้อนขอบเขตของคุณเอง
- คลิกให้สิทธิ์ API
- ป้อนข้อมูลเข้าสู่ระบบของผู้ดูแลระบบที่คุณใช้ให้สิทธิ์ GCDS
โปรดดูรายละเอียดที่หัวข้อกำหนดการตั้งค่าโดเมน Google
- คลิกรหัสการให้สิทธิ์ของ Exchange สำหรับโทเค็น
หากการประมวลผลสำเร็จ ระบบจะเปลี่ยนเส้นทางคุณไปยังขั้นตอนที่ 3: กำหนดค่าคำขอไปยัง API
- กรอกข้อมูลที่จำเป็นให้ครบถ้วน
เคล็ดลับ: คุณดูข้อมูลส่วนใหญ่ได้ในหน้าเว็บแหล่งข้อมูลเมธอด API
- คลิกส่งคำขอ
- ตรวจสอบข้อมูลเพื่อให้แน่ใจว่า API ตอบกลับตามที่คาดไว้
ข้อผิดพลาด
เปิดส่วน | ยุบทั้งหมดและกลับไปด้านบนสุด
ข้อผิดพลาดหรือความขัดแย้งเกี่ยวกับ EntityDoesNotExist/EntityExists เกิดจากอะไรตั้งค่าตัวเลือก useDynamicMaxCacheLifetime ในไฟล์การกำหนดค่า XML ตัวเลือกนี้จะกำหนดค่าให้ GCDS แคชข้อมูลได้สูงสุด 8 วัน และจะล้างแคชของชุดข้อมูลขนาดเล็กถึงขนาดกลางให้บ่อยขึ้นเพื่อลดปริมาณข้อมูลเก่าที่ไม่ได้ใช้งาน รวมทั้งลดโอกาสที่ข้อมูลในแคชจะไม่ตรงกับข้อมูลใหม่ด้วย ตัวเลือก useDynamicMaxCacheLifetime จะเปิดใช้งานโดยอัตโนมัติในการกำหนดค่าที่สร้างด้วย GCDS 3.2.1 ขึ้นไป
หมายเหตุ: ข้อผิดพลาดดังกล่าวมักเกิดจากการแก้ไขที่ทำในโดเมนของ Google โดยตรง คุณไม่ควรแก้ไขในโดเมน Google โดยตรงเมื่อใช้ GCDS ในการซิงค์ แต่ให้แก้ไขที่ผู้ใช้ กลุ่ม หรือเอนทิตีอื่นในไดเรกทอรี LDAP แทน จากนั้นจึงใช้ GCDS เพื่อซิงค์การเปลี่ยนแปลงนี้ไปยังโดเมนของ Google
หากคุณพบข้อผิดพลาดเกี่ยวกับหน่วยความจำ ให้เพิ่มขนาดของฮีปสำหรับ Java Virtual Machine โดยให้แก้ไขไฟล์ sync-cmd.vmoptions และ config-manager.vmoptions ในไดเรกทอรีการติดตั้งของ GCDS ไฟล์ที่เกี่ยวข้องจะมีลักษณะดังนี้
- -Xmx1000m (ปริมาณหน่วยความจำสูงสุดที่จัดสรรให้กับขนาดฮีป)
- -Xms64m (ปริมาณหน่วยความจำต่ำสุดที่จัดสรรให้กับขนาดฮีป)
ให้แก้ไขไฟล์ sync-cmd.vmoptions และ config-manager.vmoptions เพื่อให้การเปลี่ยนแปลงนี้มีผลทั้งจากการใช้ผ่าน sync-cmd หรือเครื่องมือจัดการการกำหนดค่า
แก้ไขตัวเลข -Xmx เพื่อเพิ่มปริมาณหน่วยความจำ "m" ที่ต่อท้ายตัวเลขคือหน่วยความจำที่มีหน่วยเป็นเมกะไบต์ (MB) จำนวนหน่วยความจำที่เหมาะสมจะขึ้นอยู่กับหน่วยความจำที่ GCDS มี และจำนวนที่ต้องใช้สำหรับการซิงค์ข้อมูล คุณอาจต้องแก้ไขตัวเลขไปเรื่อยๆ จนกว่าจะได้ขนาดที่เหมาะสม หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับปริมาณพื้นที่ว่างของ RAM ที่จำเป็นสำหรับการใช้งาน GCDS โปรดดูหัวข้อข้อกำหนดของระบบสำหรับ GCDS
ปัญหาอาจเกิดจากปัญหาด้านการกำหนดค่า เช่น การกำหนดค่ากฎการยกเว้นไม่ถูกต้อง โดยการแคช GCDS อาจซ่อนการกำหนดค่าไม่ถูกต้องประเภทนี้ได้
GCDS จะเก็บแคชของข้อมูลสำหรับบริการของ Google (เช่น Google Workspace หรือ Cloud Identity) ไว้นานสูงสุด 8 วัน ทั้งนี้ GCDS อาจล้างแคชบ่อยขึ้นโดยขึ้นอยู่กับขนาดของข้อมูลที่แคชไว้ แต่หากไม่มีการล้างแคช คุณอาจไม่เห็นอัปเดตนานถึง 8 วัน
เช่น คุณซิงค์ข้อมูล LDAP แล้วสร้างกลุ่มใหม่สำหรับบริการของ Google (เช่น Google Workspace หรือ Cloud Identity) จากนั้นจึงสร้างกฎการยกเว้นเพื่อให้ไม่ต้องซิงค์กลุ่มนั้นอีก กฎการยกเว้นแบบนี้ไม่ถูกต้องและจะใช้ไม่ได้ แต่การซิงค์ครั้งต่อไปนี้จะเรียกข้อมูลที่แคชไว้และกลุ่มดังกล่าวจะยังอยู่ในบริการของ Google เหมือนเดิม เมื่อซิงค์อีกครั้งตอนที่ล้างแคชไปแล้ว การกำหนดค่าที่ไม่ถูกต้องนี้จะทำให้ระบบนำกลุ่มออกจากบริการของ Google
วิธีล้างแคชด้วยตัวเอง
- ซิงค์จากเครื่องมือจัดการการกำหนดค่า แล้วเลือกตัวเลือกที่ล้างแคชเมื่อซิงค์
- ซิงค์จากคำสั่งและใช้อาร์กิวเมนต์ -f เพื่อบังคับให้ล้างแคช
- แก้ไขไฟล์การกำหนดค่า XML เพื่อตั้งค่า maxCacheLifetime เป็น 0
ข้อสำคัญ: การบังคับให้ล้างแคชอาจทำให้ใช้เวลาในการซิงค์นานขึ้นมาก
ผู้ใช้และกลุ่ม
เปิดส่วน | ยุบทั้งหมดและกลับไปด้านบนสุด
ทำไม GCDS จึงพยายามสร้างผู้ใช้ Google ที่มีอยู่แล้วหากคุณได้รับข้อผิดพลาด 409: มีเอนทิตีนี้อยู่แล้ว แสดงว่า GCDS กำลังพยายามสร้างผู้ใช้ Google ที่มีอยู่แล้ว หากคุณไม่เห็นข้อผิดพลาดในการซิงค์ครั้งต่อๆ ไป อาจเป็นเพราะแคชของ GCDS นั้นล้าสมัย และคุณจะข้ามข้อผิดพลาดดังกล่าวไปก็ได้
หากปัญหาเกิดขึ้นในทุกๆ การซิงค์หรือทุกๆ หลายวัน สาเหตุที่เป็นไปได้มากที่สุดมีดังนี้
- กฎการยกเว้นผู้ใช้ Google นั้นกว้างเกินไป ซึ่งจะทำให้กฎจับคู่ผู้ใช้ Google บางรายที่มีอยู่ในไดเรกทอรี LDAP ด้วย
- คำค้นหานั้นแคบเกินไป ซึ่งจะทำให้คำค้นหาดังกล่าวไม่จับคู่กับผู้ใช้ Google บางรายที่มีอยู่ในไดเรกทอรี LDAP ด้วย
ทั้ง 2 กรณีข้างต้นอาจทำให้ GCDS ยกเว้นผู้ใช้ Google ที่มีอยู่แล้วได้ หากผู้ใช้ดังกล่าวปรากฏในผลลัพธ์ของกฎการค้นหาผู้ใช้ LDAP เครื่องมือ GCDS จะพยายามสร้างผู้ใช้ในบัญชี Google ของคุณ
หากต้องการแก้ไขปัญหานี้ ให้ปรับกฎการยกเว้นหรือคำค้นหา หรือหากต้องการให้ GCDS ยกเว้นผู้ใช้ในไดเรกทอรี LDAP โดยสิ้นเชิง คุณก็สามารถปรับกฎการค้นหาผู้ใช้ LDAP หรือสร้างกฎการยกเว้นผู้ใช้ LDAP ได้ โปรดดูรายละเอียดที่หัวข้อยกเว้นข้อมูลด้วยกฎการยกเว้นและการค้นหา
GCDS เปิด INDEPENDENT_GROUP_SYNC โดยค่าเริ่มต้นเพื่อซิงค์ข้อมูลสมาชิกกลุ่มโดยแยกจากผลลัพธ์ของกฎการค้นหาผู้ใช้ หากคุณใช้แอตทริบิวต์การอ้างอิงสมาชิกเพื่อซิงค์ข้อมูลกลุ่ม GCDS จะพยายามหาอีเมลของผู้ใช้ทุกรายในไดเรกทอรี LDAP โดยไม่คำนึงถึงกฎการค้นหาผู้ใช้
หากต้องการซิงค์ข้อมูลสมาชิกกลุ่มตามผลลัพธ์ของกฎการค้นหาผู้ใช้เท่านั้น ให้นำ INDEPENDENT_GROUP_SYNC ออกจากไฟล์ XML ของการกำหนดค่า ซึ่ง GCDS จะทำสิ่งต่อไปนี้
- ใช้ผลลัพธ์ของกฎการค้นหาผู้ใช้เพื่อแก้ปัญหาการเป็นสมาชิกกลุ่ม
- ซิงค์เป็นสมาชิกกลุ่มที่ผู้ใช้ดังกล่าวรวมอยู่ในการซิงค์ผู้ใช้เท่านั้น
- ใช้กฎการค้นหาผู้ใช้ แม้ว่าคุณจะปิดการซิงค์บัญชีผู้ใช้ในการตั้งค่าทั่วไปก็ตาม
(ผลลัพธ์จะไม่ซิงค์กับ Google เป็นผู้ใช้ แต่เป็นสมาชิกกลุ่ม หากผู้ใช้ที่มีสิทธิ์ถือว่าเป็นสมาชิกกลุ่มด้วย)
ปกติแล้วเราจะไม่แนะนำให้ซิงค์ด้วยวิธีนี้ โดยเฉพาะกรณีที่คุณซิงค์รายชื่อติดต่อที่แชร์และมีสมาชิกกลุ่มที่อยู่ในรายชื่อติดต่อ ในกรณีนี้ รายชื่อติดต่อจะไม่ซิงค์ข้อมูลเป็นสมาชิกกลุ่ม
ปัญหานี้จะเกิดขึ้นเมื่อแอตทริบิวต์ LDAP ที่กำหนดค่าเป็นแอตทริบิวต์ชื่อกลุ่มไม่มีอีเมลแบบเต็ม คุณจะแก้ไขปัญหานี้ได้โดยตรวจสอบกฎการค้นหากลุ่มของคุณ และตรวจสอบว่า GCDS ใช้อีเมลแบบเต็มสำหรับชื่อกลุ่ม โปรดใช้วิธีการใดวิธีการหนึ่งดังต่อไปนี้
- ตั้งค่าแอตทริบิวต์ชื่อกลุ่มเป็นแอตทริบิวต์ LDAP อื่นที่ระบุอีเมลแบบเต็มสำหรับแต่ละกลุ่ม เช่น อีเมล
- เปิดแทนที่ชื่อโดเมนในอีเมล LDAP ในการตั้งค่าโดเมน Google เพื่อให้แอตทริบิวต์ชื่อกลุ่มตรงกับชื่อกลุ่มของด้าน Google
- เพิ่มชื่อโดเมนไปยังชื่อกลุ่มโดยระบุค่าต่อท้ายชื่อกลุ่มในกฎการค้นหากลุ่ม
ตรวจสอบว่าคุณเลือกฟิลด์ประเภทของเซิร์ฟเวอร์ในส่วนของการกำหนดค่า LDAP ให้เป็น MS Active Directory
ระบบจะใช้ตัวเลือกนี้ (แสดงเป็น SUPPRESS_DOMAIN ในไฟล์ XML) หากอีเมลในไดเรกทอรี LDAP อยู่ในโดเมนอื่นที่ไม่ใช่โดเมน Google ของคุณ เมื่อเปิดตัวเลือกนี้ GCDS จะตัดส่วนของโดเมนออกจากอีเมลทั้งหมดที่อ่าน
การประมวลผลจะทำโดยไม่มีชื่อโดเมน หากใช้กฎการยกเว้นตามอีเมล โปรดพิจารณาเฉพาะส่วนชื่อของอีเมลสำหรับกฎนี้
เช่น หากปิดตัวเลือกแทนที่ชื่อโดเมนในอีเมล LDAP ไว้ แล้วสร้างกฎการยกเว้นการทำงานแบบตรงทั้งหมดอยู่ คุณต้องป้อน luka@example.com เป็นอีเมลของผู้ใช้ที่จะจับคู่ หากเปิดใช้แทนที่ชื่อโดเมนในอีเมลของ LDAP ไว้ ให้ใช้ luka เพราะคุณจะค้นหาด้วย luka@example.com ไม่พบเนื่องจากระบบได้ตัด @example.com ออกไปก่อนการค้นหาแล้ว
ขณะจัดสรรกลุ่มโดยใช้ GCDS คุณจะซ้อนกลุ่มไดนามิกใต้กลุ่มคงที่ไม่ได้ (หรือซ้อนกลุ่มคงที่ใต้กลุ่มไดนามิก) GCDS กำหนดให้ค้นหากลุ่มคงที่หรือกลุ่มไดนามิกแยกกันต่างหาก แต่กลุ่มที่ซ้อนกันอยู่จะต้องอยู่ในการค้นหาเดียวกัน
คุณอาจเปลี่ยนกลุ่มไดนามิกให้เป็นกลุ่มคงที่ได้ โดยกำหนดงานขึ้นมาให้ทำการค้นหากลุ่มแบบไดนามิกโดยอัตโนมัติเป็นระยะๆ เพื่อป้อนข้อมูลกลุ่มคงที่ในไดเรกทอรี จากนั้น GCDS จึงจะนำกลุ่มคงที่ (ที่สร้างจากกลุ่มไดนามิก) ไปจัดสรรต่อไปได้ พร้อมทั้งหยุดการจัดสรรกลุ่มไดนามิกดังกล่าว
ผลลัพธ์ของการค้นหา LDAP จะขึ้นอยู่กับการตั้งค่าเครื่องมือจัดการการกำหนดค่าและเซิร์ฟเวอร์ LDAP โปรดใช้เคล็ดลับการแก้ปัญหาต่อไปนี้หากกฎการค้นหา LDAP แสดงผลลัพธ์ที่ไม่คาดคิด โดยตรวจสอบว่าได้ดำเนินการดังนี้
- การค้นหา LDAP ได้รับการตั้งค่าอย่างถูกต้องในเครื่องมือจัดการการกําหนดค่า - เมื่อคุณตั้งค่ากฎการค้นหา ให้คลิกทดสอบการค้นหา LDAP เพื่อยืนยัน โปรดดูรายละเอียดที่หัวข้อใช้กฎการค้นหา LDAP เพื่อซิงค์ข้อมูล
- การค้นหาหลายรายการไม่ขัดแย้งกัน - ตรวจสอบว่าคุณไม่ได้ตั้งค่ากฎการค้นหาหรือกฎการยกเว้นที่เปลี่ยนผลลัพธ์ของการค้นหา
- ผู้ใช้ที่ได้รับอนุญาตสําหรับเซิร์ฟเวอร์ LDAP มีสิทธิ์เพียงพอ โปรดตรวจสอบว่าผู้ดูแลระบบที่ทำหน้าที่ตรวจสอบสิทธิ์เซิร์ฟเวอร์ LDAP สามารถใช้บรรทัดคําสั่งในเซิร์ฟเวอร์เดียวกันได้ ลองทำการค้นหาในเซิร์ฟเวอร์ LDAP และยืนยันผลลัพธ์
คุณอาจพบข้อความแสดงข้อผิดพลาดที่ระบุว่าสร้างกลุ่ม ... ไม่ได้ ข้อความ: ไม่ได้รับสิทธิ์ให้เข้าถึงทรัพยากร/API นี้ในบันทึกของ GCDS
หากต้องการแก้ปัญหา ให้ตรวจสอบว่าแอตทริบิวต์ Active Directory (AD) ที่มีโดเมนสำหรับอีเมลของผู้ใช้และกลุ่มตรงกับโดเมนที่บัญชีผู้ดูแลระบบขั้นสูงใช้
รายชื่อติดต่อและปฏิทิน
เปิดส่วน | ยุบทั้งหมดและกลับไปด้านบนสุด
ทำไมจึงมีรายชื่อติดต่อซ้ำกันในไดเรกทอรีของโดเมนหลังจากซิงค์กับ GCDSปัญหานี้มักเกิดขึ้นเมื่อคุณซิงค์รายชื่อติดต่อที่ใช้ร่วมกัน รวมทั้งกำหนดกฎการค้นหาไม่ถูกต้อง
ออบเจกต์ที่เกี่ยวข้องซึ่งคุณจะซิงค์กับ GCDS ได้มี 2 ประเภทดังนี้
- โปรไฟล์ผู้ใช้ - ผู้ใช้ในโดเมน Google ของคุณที่มีข้อมูลอื่นเพิ่มเข้ามา เช่น หมายเลขโทรศัพท์และที่อยู่ คุณจะซิงค์โปรไฟล์ได้เฉพาะสำหรับผู้ใช้ที่อยู่ในโดเมนของคุณเท่านั้น
- รายชื่อติดต่อที่ใช้ร่วมกัน - รายชื่อติดต่อของบุคคลภายนอกที่ผู้ใช้ในโดเมนจำเป็นต้องใช้
ถ้าต้องการแก้ไขปัญหานี้ ให้ปรับกฎการค้นหารายชื่อติดต่อที่ใช้ร่วมกันเพื่อยกเว้นผู้ใช้ในโดเมน เมื่อซิงค์ครั้งถัดไป GCDS จะพยายามลบรายชื่อติดต่อที่ซ้ำกันออก คุณอาจต้องปรับข้อจำกัดในการลบรายชื่อติดต่อที่ใช้ร่วมกันสำหรับการซิงค์ครั้งแรก
ผู้ใช้อาจมองไม่เห็นสถานที่ทำงานหลักของตนเองใน Google ปฏิทินในขณะที่กำลังวางกำหนดการหรือจัดการประชุมได้เป็นบางครั้ง
หากพบปัญหานี้ โปรดตรวจสอบว่าได้ตั้งค่าประเภทสถานที่และแอตทริบิวต์ของพื้นที่ให้เป็น "โต๊ะทำงาน"
กฎ
เปิดส่วน | ยุบทั้งหมดและกลับไปด้านบนสุด
ทำไมกฎการค้นหาจึงไม่พบผลลัพธ์ใดๆ เลยหากคุณประสบปัญหาเกี่ยวกับผลการค้นหา ให้ตรวจสอบดังนี้
- ขอบเขตของกฎ คุณอาจต้องตั้งค่าขอบเขตให้เป็น Sub-tree
- กฎการค้นหาที่คุณใช้อยู่ถูกต้องแล้ว
- แอตทริบิวต์ที่ใช้มีอยู่และมองเห็นได้
การค้นหา LDAP ยืนยันว่าการค้นหาในเซิร์ฟเวอร์ LDAP ใช้ชื่อผู้ใช้ของผู้ดูแลระบบเดียวกันกับที่กำหนดค่าไว้ใน GCDS
โปรดดูรายละเอียดที่หัวข้อใช้กฎการค้นหา LDAP เพื่อซิงค์ข้อมูล
คุณอาจใช้แบบอักษรที่ใหญ่เกินไปสำหรับหน้าจอ กรอบข้อความใช้ไม่ได้กับแบบอักษรขนาดใหญ่หรือใหญ่มาก ให้เปลี่ยนขนาดแบบอักษรหรือแก้ไขไฟล์ XML โดยตรง
หัวข้อที่เกี่ยวข้อง
ปัญหาที่ทราบเกี่ยวกับ Google Workspace
Google, Google Workspace และเครื่องหมายและโลโก้ที่เกี่ยวข้องเป็นเครื่องหมายการค้าของ Google LLC ชื่อบริษัทและชื่อผลิตภัณฑ์อื่นๆ ทั้งหมดเป็นเครื่องหมายการค้าของ บริษัทที่เกี่ยวข้อง
