Устранение неполадок в GCDS

Если при синхронизации возникают сбои, проверьте правильность настроек конфигурации.

1. В Диспетчере конфигураций откройте XML-файл, используемый для настройки синхронизации.
2. Чтобы проверить подключение к серверу LDAP, на странице LDAP Connections (Соединения LDAP) нажмите Test Connections (Протестировать соединения).
3. Чтобы проверить отправку тестовых уведомлений, выберите Test Notification (Протестировать уведомления) на странице Notifications (Уведомления).
4. Чтобы убедиться, что вы заполнили все необходимые поля, а синхронизация работает корректно, на странице Sync (Синхронизация) нажмите Simulate Sync (Моделировать синхронизацию).

В редких случаях специалисты службы поддержки могут попросить вас включить полную детализацию HTTP-журналов в дополнение к детализации на уровне Trace (Трассировка) для журналов GCDS. Это поможет узнать, какие именно запросы к API отправило приложение GCDS и какие ответы оно получило от API Google.

Обратите внимание! В подробных HTTP-журналах может содержаться конфиденциальная информация. Прежде чем отправлять их в службу поддержки, удалите эту информацию (например, данные в полях refresh_token и access_token).

Чтобы включить ведение подробных HTTP-журналов, выполните следующие действия:

1. С помощью команды sync-cmd или Диспетчера конфигураций убедитесь, что приложение GCDS не запущено.
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. Чтобы предотвратить создание больших файлов журнала в будущем, удалите строки, добавленные на шаге 4.
8. Затем отправьте в службу поддержки следующие файлы:
   • XML-файл.
   • Журналы уровня трассировки и файлы gcdshttp*.log из последней синхронизации.

СОВЕТ. Если вы хотите включить ведение журнала для нового класса, добавьте строку в формате class.fqdn.level = ALL. Дублировать весь блок настроек не нужно.

Размер записываемых запросов и ответов ограничен 16 КБ. Если вам встретится запись в журнале, которая усечена в связи с этим ограничением, используйте прокси-сервер для отладки, например Fiddler.

Чтобы включить Fiddler, выполните следующие действия.

Перезапустите GCDS, чтобы изменения вступили в силу.

Хранилище доверенных сертификатов Windows недоступно пользователям GCDS на Linux. В таком случае необходимо импортировать корневой сертификат Fiddler в базу доверенных сертификатов Java в GCDS. Подробные инструкции приведены в статье Устранение неполадок, связанных с сертификатом.

1. Перейдите по пути, где установлен GCDS, например C:\Program Files\Google Cloud Directory Sync.
2. Добавьте в файлы .vmoptions (например, config-manager.vmoptions или sync-cmd.vmoptions) следующие флаги, чтобы отключить проверку CRL:

   -Dcom.sun.security.enableCRLDP=false

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

   1. Настройте Fiddler как прокси-сервер в настройках прокси-сервера конфигурации домена Google. В поле имени хоста добавьте локальный IP-адрес 127.0.0.1. Порт по умолчанию – 8888, но вы можете проверить это, открыв Fiddler, выбрав Options > Connections (Параметры > Подключения) и посмотрев значение в поле Fiddler Classic listens on port (Fiddler Classic прослушивает порт).

Если у вас есть проблемы при настройке хоста ретранслятора SMTP для уведомлений, попробуйте выполнить описанные ниже действия по устранению неполадок.

Ошибка подключения с сообщением о неизвестном хосте SMTP

1. Откройте командную строку.
2. Чтобы проверить, сопоставляется ли заданное имя хоста SMTP-сервера с IP-адресом, введите следующую команду:

   nslookup smtp-host-name.com

Ошибка подключения с сообщением о том, что не удалось подключиться к SMTP

Проверьте, может ли сервер, на котором запущена утилита GCDS, подключиться к хосту SMTP.

1. Чтобы проверить подключение, в командной строке Windows или терминале введите следующую команду:

   telnet smtp.gmail.com 587

2. Если хосту не удается подключиться, проверьте правила брандмуэра для входящего трафика SMTP-сервера и для исходящего трафика сервера GCDS.
3. Убедитесь, что трафик через порт SMTP разрешен.

Ошибка "Не удалось преобразовать сокет в TLS" в журналах

Отключите проверки списка отзыва сертификатов (CRL). Подробнее о том, как GCDS проверяет списки отзыва сертификатов…

Инструкции приведены в статье Работа с файлами конфигурации.

Если данные LDAP в журналах GCDS уровня Trace (Трассировка) не соответствуют ожидаемой информации на сервере LDAP (например, отсутствует пользователь или у атрибута неправильное значение), экспортируйте данные из каталога LDAP в формате LDIF. Специалисты службы поддержки могут сравнить эти данные с данными LDAP в журналах GCDS.

При экспорте данных используйте инструмент запросов LDAP, например ldapsearch (Linux) или ldifde (Windows) и воссоздайте условия, в которых работает GCDS:

• используйте те же настройки подключения, что и для GCDS;
• запустите инструмент запросов на том же компьютере, на котором работает GCDS;
• укажите то же имя пользователя, которое используется GCDS для доступа к LDAP.

Пример

В журналах GCDS нет атрибута mail пользователей и указано следующее правило поиска GCDS:

• Base DN (Базовое уникальное имя): ou=Ireland,dc=altostrat,dc=com
• Scope (Область действия): Subtree
• Search filter (Фильтр поиска): (&(objectCategory=person)(objectClass=user))
• Server (Сервер): dc01.altostrat.com
• Port (Порт): 636
• Protocol (Протокол): 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 паролем пользователя LDAP, заданным в GCDS).

Если в выходных данных (out.ldif) не будет атрибута mail для затронутого пользователя, то проблема в инфраструктуре LDAP. Она может быть связана с разрешениями пользователя, которого вы выбрали для доступа к LDAP (например, и в OpenLDAP, и в Active Directory разрешено задавать разрешения на уровне атрибутов). Возможно, атрибут не продублирован в глобальном каталоге, если вы используете порт глобального каталога, например 3268 или 3269.

Если в выходных данных есть атрибут mail для затронутого пользователя, отправьте в службу поддержки Google Workspace следующие сведения:

• файл out.ldif;
• скриншот командной строки или окна терминала, где вы выполнили команду
  (не забудьте сначала скрыть пароль);
• журнал GCDS уровня Trace.

Описание. Проблема возникает в Google Cloud Directory Sync (GCDS) версии 5.0.22, когда вы выполняете следующие действия:

1. В Диспетчере конфигураций нажмите Google Domain (Домен Google), а затем Configuration Exclusion Rules (Правила исключения конфигурации).
2. В поле Users Search Query (Запрос на поиск пользователей) введите запрос на поиск пользователя и сохраните файл конфигурации.
3. Удалите этот запрос и сохраните файл конфигурации.
4. Сравните файл конфигурации на шаге 2 с файлом на шаге 3.

   Файл конфигурации будет одинаковым. Удаленный запрос не был сохранен в файле.

Временное решение. Откройте файл конфигурации и вручную удалите параметр .

Вам потребуется сервер, который может отправлять сообщения. При запуске 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. Используйте документацию по API

1. Перейдите на страницу обзора документации по Admin SDK API.
2. В левой части страницы нажмите Directory API, а затем в списке REST Resources выберите ресурс REST, к которому хотите отправить запрос.
3. Справа выберите способ и нажмите Попробовать.

   Если на странице документации по API нет кнопки Попробовать, следуйте инструкциям в разделе "Вариант 2. Используйте OAuth 2.0 Playground".

4. Укажите учетные данные администратора, которые вы использовали при авторизации GCDS.

   Дополнительные сведения можно найти в разделе Как настроить домен Google.

5. Изучите информацию, чтобы убедиться, что от API получен правильный ответ.

Вариант 2. Используйте OAuth 2.0 Playground

1. Откройте OAuth 2.0 Playground.
2. Выберите один из вариантов:
   • Выберите область действия из списка.
   • Скопируйте область действия из списка Области действия авторизации на странице документации по API, а затем вставьте в поле Укажите собственные области действия.
3. Нажмите Авторизовать API.
4. Укажите учетные данные администратора, которые вы использовали при авторизации GCDS.

   Дополнительные сведения можно найти в разделе Как настроить домен Google.

5. Нажмите Обменять код авторизации на токены.

   Если процесс будет выполнен успешно, вы будете направлены на Шаг 3. Настройка запроса к API.

6. Укажите требуемые сведения.

   Примечание. Большинство информации можно найти на веб-странице документации по API.

7. Нажмите Отправить запрос.
8. Изучите информацию, чтобы убедиться, что от API получен правильный ответ.

Описание. Проблема возникает с Google Cloud Directory Sync (GCDS). Если вы измените основной адрес электронной почты пользователя на сервере LDAP, то переименование не будет учтено, когда GCDS будет синхронизировать лицензию пользователя. GCDS попытается добавить лицензию к переименованному пользователю, и в результате возникнет ошибка 412.

Описание. Google Cloud Directory Sync (GCDS) использует уникальный идентификатор для установления связи между пользователями в Google Workspace и внешнем каталоге. У пользователей Microsoft Active Directory есть идентификатор ObjectGUID, а у пользователей Microsoft Azure Active Directory – Object ID.

Если вы повторно создадите пользователя во внешнем каталоге, новый пользователь получит исходный идентификатор ObjectGUID или Object ID. Однако поскольку адрес электронной почты нового пользователя уже связан с удаленным пользователем в Workspace, при синхронизации возникает ошибка.

Решение. Если вы планируете повторно создать пользователя с тем же адресом электронной почты, сохраните ObjectGUID или Object ID пользователя во внешнем каталоге. Или же переименуйте или удалите адрес электронной почты пользователя в Workspace, чтобы GCDS мог связать новый аккаунт пользователя с новым пользователем во внешнем каталоге.

В XML-файле конфигурации включите параметр useDynamicMaxCacheLifetime. Он разрешает кеширование данных максимум за восемь дней, благодаря чему кеш очищается чаще и информация удаляется небольшими порциями. Это позволяет избежать хранения устаревших данных и конфликтов с новой информацией. Параметр useDynamicMaxCacheLifetime автоматически включается в конфигурациях, созданных в GCDS 3.2.1 и более поздних версий.

Примечание. Такие ошибки обычно возникают, когда вы вносите изменения напрямую через домен Google. При работе с GCDS этого нужно избегать. Редактируйте данные о пользователях, группах и других объектах в каталоге LDAP, а затем с помощью GCDS синхронизируйте изменения с доменом Google.

Если возникают ошибки, связанные с объемом памяти, увеличьте размер динамически распределяемой памяти, доступный виртуальной машине Java. Для этого отредактируйте файлы sync-cmd.vmoptions и config-manager.vmoptions в папке, где установлено приложение GCDS. Записи выглядят так:

• -Xmx1000m (максимальный объем динамически распределяемой памяти);
• -Xms64m (минимальный объем динамически распределяемой памяти).

Чтобы распространить изменения как на команду sync-cmd, так и на Диспетчер конфигураций, отредактируйте оба файла (sync-cmd.vmoptions и config-manager.vmoptions).

Чтобы увеличить объем памяти, измените число в параметре -Xmx. Буква m после него означает мегабайты. Оптимальное значение этой величины зависит от количества доступной памяти на сервере GCDS и от ее объема, необходимого для синхронизации. Для подбора наилучшего варианта может потребоваться изменить это число несколько раз. Подробнее об оптимальном объеме памяти для работы GCDS…

Возможно, проблема заключается в неправильной конфигурации правила исключения. Кеширование GCDS может скрыть ее.

Данные сервиса Google (например, Google Workspace или Cloud Identity) хранятся в кеше GCDS до восьми дней, однако они могут удаляться чаще в зависимости от их объема. Если кеш не очищен, может пройти до восьми дней, прежде чем изменения вступят в силу.

Например, вы синхронизируете данные каталога LDAP и создаете группу в сервисе Google (это может быть Google Workspace или Cloud Identity). Затем вы задаете правило, чтобы исключить ее из последующих синхронизаций. Оно настроено неправильно и не сработает. Однако при следующей синхронизации будут запрошены данные из кеша, и группа останется в сервисе Google. При новой синхронизации после очистки кеша группа будет удалена из сервиса Google из-за неправильной конфигурации.

Чтобы очистить кеш вручную, выполните следующие действия:

• Запустите синхронизацию из Диспетчера конфигураций и выберите очистку кеша.
• Запустите синхронизацию с помощью командной строки, используя аргумент -f, чтобы принудительно очистить кеш.
• Отредактируйте файл конфигурации XML, установив для параметра maxCacheLifetime значение "0".

Внимание! Принудительная очистка кеша может значительно увеличить время синхронизации.

Если возникает ошибка 409: такой объект уже существует или ошибка конфликта аккаунтов, GCDS пытается создать пользователя с адресом электронной почты, который уже используется в качестве обычного личного аккаунта, обычного рабочего аккаунта или существующего управляемого аккаунта. Чтобы устранить эту проблему, ознакомьтесь со статьями Как управлять конфликтующими аккаунтами с помощью GCDS и Как устранять ошибки, связанные с дублирующимися аккаунтами. Если при последующих синхронизациях ошибка не появится, скорее всего, кеш GCDS был устаревшим и ошибку можно игнорировать.

Если ошибка происходит при каждой синхронизации или каждые несколько дней, наиболее вероятны следующие причины:

• Правило исключения пользователей Google слишком широкое – под него подпадают некоторые пользователи, которые также есть в каталоге LDAP.
• Запрос слишком узкий – он не соответствует некоторым пользователям Google, которые также есть в каталоге LDAP.

В обоих случаях GCDS может игнорировать пользователей Google, которые уже существуют. Если они существуют в результатах правила поиска пользователей LDAP, GCDS попытается создать их в вашем аккаунте Google.

Чтобы устранить эту проблему, измените правило исключения или поисковый запрос. Если же вы хотите, чтобы GCDS полностью игнорировал пользователей в каталоге LDAP, измените правило поиска пользователей LDAP или создайте правило исключения пользователей LDAP. Подробнее о том, как использовать правила исключения и запросы, чтобы не синхронизировать определенные данные…

Иногда атрибуты специальной схемы, особенно недавно созданные, могут не синхронизироваться из каталога LDAP с аккаунтами пользователей Google. В этом случае поля атрибутов для пользователей Google останутся пустыми даже после успешной синхронизации.

Возможные причины:

• У авторизованного пользователя сервера LDAP, настроенного в Google Cloud Directory Sync (GCDS), нет доступа на чтение к этим атрибутам в каталоге LDAP.
• Если вы используете сервер глобального каталога (порт 3268 или 3269) и не установили флажок Replicate this attribute to the Global Catalog (Реплицировать этот атрибут в глобальный каталог) в схеме Active Directory, ваши атрибуты специальной схемы не будут найдены на сервере Google Cloud во время синхронизации.

Чтобы убедиться, что атрибуты пользовательской схемы синхронизируются, выполните следующие действия:

1. Обратитесь к администратору LDAP, чтобы убедиться, что у пользователя, настроенного в GCDS для аутентификации LDAP, есть доступ на чтение ко всем атрибутам, которые не синхронизируются.
2. На том же компьютере, на котором запущен GCDS, используйте LDAP-браузер, чтобы подключиться к серверу LDAP. При подключении убедитесь, что вы используете того же пользователя, что и GCDS. Найдите одного из затронутых пользователей и убедитесь, что вы можете просматривать значения атрибутов, которые не синхронизируются.
3. Убедившись, что разрешения заданы правильно, очистите кеш GCDS и запустите синхронизацию.

Если атрибуты специальной схемы по-прежнему не синхронизируются, соберите данные GCDS и обратитесь в службу поддержки. С подробной информацией можно ознакомиться в статье Какая информация о GCDS необходима для обращения в службу поддержки.

По умолчанию в GCDS включен параметр INDEPENDENT_GROUP_SYNC. При этом приложение синхронизирует участников группы независимо от правил поиска пользователей. Если для синхронизации групп вы используете атрибуты ссылок на участников, GCDS попытается получить адреса электронной почты каждого из них в каталоге LDAP.

Чтобы синхронизировать участников группы только на основе результатов поиска пользователей, удалите параметр INDEPENDENT_GROUP_SYNC из XML-файла конфигурации. GCDS:

• берет информацию об участниках группы из результатов поиска пользователей;
• синхронизирует в качестве участников группы только тех пользователей, которые включены в правила синхронизации;
• соблюдает правила поиска пользователей, даже если вы отключите синхронизацию аккаунтов в разделе Общие настройки.

  Но если соответствующие пользователи также являются участниками группы, для них результаты синхронизируются с Google как для участников группы.

Как правило, это нежелательный способ синхронизации, особенно если вы синхронизируете общие контакты, а некоторые из них являются участниками группы. В таком случае контакты не будут синхронизированы как участники группы.

Эта проблема возникает, если в атрибуте LDAP, который назначен атрибутом названия группы, не указан полный адрес электронной почты. Чтобы решить эту проблему, проверьте правила поиска групп и убедитесь, что GCDS использует в качестве названий групп полные адреса. Для этого выполните одно из следующих действий:

• Назначьте в качестве атрибута названия группы другой атрибут LDAP, в котором указывается полный адрес электронной почты (например, mail).
• В разделе Google Domain Settings (Настройки домена Google) включите параметр Replace domain names in LDAP email addresses (Заменять доменные имена в адресах электронной почты LDAP). В этом случае атрибут названия группы будет соответствовать данным в сервисах Google.
• Добавьте к названию группы доменное имя. Для этого укажите суффикс названия группы в правиле поиска группы.

Откройте раздел LDAP Configuration (Конфигурация LDAP) и убедитесь, что в поле для типа сервера указано значение MS Active Directory.

Этот параметр, задаваемый в XML-файле в виде строки SUPPRESS_DOMAIN, используется, если адреса электронной почты в каталоге LDAP находятся не в вашем домене Google. Если этот параметр включен, GCDS отсекает у адресов доменную часть.

Если вы задаете правило исключения на основе адресов электронной почты, их доменная часть не будет учитываться при обработке данных.

Например, если параметр Replace domain names in LDAP email addresses (Заменять доменные имена в адресах электронной почты LDAP) отключен, то при создании правила исключения с точным соответствием нужно указывать полный адрес: luka@example.com. Если вы установили флажок Replace domain names in LDAP email addresses (Заменять доменные имена в адресах электронной почты LDAP), используйте luka. При сравнении с образцом luka@example.com соответствие не будет установлено, поскольку вторая часть адреса (@example.com) была удалена до сравнения.

При синхронизации групп с помощью GCDS нельзя вкладывать динамические группы в статические (или наоборот). В GCDS запросы для статических и динамических групп должны быть раздельными, в то время как все вложенные группы должны включаться в один запрос.

Попытайтесь реализовать динамические группы в виде статических. Для этого можно создать автоматизированную задачу, которая будет периодически запрашивать данные из каждой динамической группы каталога и подставлять их в статические. В результате GCDS сможет использовать для синхронизации статические группы (созданные на основе динамических) и не синхронизировать динамические.

Результаты запросов LDAP зависят от настроек Диспетчера конфигураций и сервера LDAP. Если правило поиска LDAP возвращает неожиданный результат, используйте приведенные ниже советы по устранению неполадок. Убедитесь, что:

• Запрос LDAP указан правильно в Диспетчере конфигураций. При настройке правила поиска нажмите Test LDAP query (Проверить запрос LDAP), чтобы проверить его. Подробнее об использовании правил поиска LDAP для синхронизации данных…
• Нет противоречий между несколькими запросами. Проверьте, не настроили ли вы правило поиска или исключения, которое меняет результат запроса.
• У авторизованного пользователя сервера LDAP есть необходимые разрешения. Убедитесь, что администратор, который выполняет аутентификацию на сервере LDAP, может использовать на нем командную строку. Попробуйте выполнить запрос на сервере LDAP и проверьте результаты.

В журналах GCDS вы можете увидеть сообщение об ошибке Group ... could not be created. Message: Not Authorized to access this resource/api. (Не удалось создать группу "…". Сообщение: нет права на доступ к этому ресурсу/API.)

Чтобы устранить неполадку, убедитесь, что атрибут Active Directory (AD), который содержит домен адресов электронной почты пользователя и группы, соответствует домену, используемому для аккаунта суперадминистратора.

Проблема с Google Cloud Directory Sync (GCDS) может возникнуть в двух ситуациях.

Ситуация 1. Вы переименовали адрес электронной почты группы в Microsoft Active Directory (AD) после того, как группа была синхронизирована с Google Workspace. После синхронизации GCDS удаляет текущую группу и создает новую группу с другим адресом электронной почты.

Решение 1. Не меняйте адрес электронной почты группы в AD.

Решение 2. Вручную укажите одинаковый электронный адрес группы в AD и Google Workspace.

Ситуация 2. Проблема возникает в следующих случаях:

1. Адрес электронной почты группы содержит специальные символы (например, !#$%&'*+/=?^_`).
2. Группа была синхронизирована с Google Workspace с использованием GCDS более ранней версии, чем 5.0.20.
3. Вы обновили GCDS до версии 5.0.20 или более поздней.
4. После синхронизации GCDS пытается удалить группу и создать ее заново с использованием специальных символов.

Решение 1. Удалите специальные символы из электронного адреса группы в AD.

Решение 2. Добавьте специальные символы в адрес электронной почты в Google Группах.

Обычно эта проблема возникает, если при синхронизации общих контактов правила поиска заданы некорректно.

С помощью GCDS можно синхронизировать объекты двух типов:

• Профили пользователей. В профиле содержатся дополнительные данные, такие как номера телефонов и адреса, и его можно синхронизировать, только если пользователь зарегистрирован в вашем домене.
• Общие контакты. Это пользователи за пределами домена, с которыми общаются ваши сотрудники.

Чтобы устранить проблему, измените правила поиска общих контактов и исключите из них пользователей в вашем домене. При следующей синхронизации GCDS попытается удалить лишние записи. Возможно, перед этим потребуется изменить ограничения на удаление общих контактов.

В некоторых случаях при планировании мероприятий в Google Календаре адрес основного места работы пользователя не показывается.

Чтобы этого не происходило, установите для атрибутов типа местоположения и области значение desk.

Если с результатами поиска что-то не так, проверьте следующее:

• Область действия правила. Возможно, для нее нужно задать значение Sub-tree.
• Корректность правила.
• Что используемые атрибуты существуют и являются видимыми.
• Запрос LDAP. Убедитесь, что в запросе на сервере LDAP используется имя пользователя, которое настроено в GCDS.

Подробнее об использовании правил поиска LDAP для синхронизации данных…

Возможно, вы используете слишком крупный шрифт. В диалоговом окне большие или очень большие шрифты отображаются некорректно. Измените размер шрифта или отредактируйте сам XML-файл.

Если при поиске импортируется только 1000 доступных пользователей (или размер страницы LDAP по умолчанию), возможно, в настройках имени хоста LDAP в Диспетчере конфигураций указан общий домен или корневой домен леса, который выдает ссылки на объекты в базовом уникальном имени.

Для устранения этой проблемы обновите Диспетчер конфигураций, чтобы значение параметра "Имя хоста" совпадало со значением параметра "Базовое уникальное имя". Можно также использовать контроллер домена (например, dc01.example.com), который содержит объекты аккаунтов пользователей в базовом уникальном имени.