Как отключить интеграцию с Office Communicator в CRM4?

[Артем Enot Грунин]

Примерчик из ссылки говорит о переименовании учетки, а не путанице между доменами. Вещи принципиально разные. Если вы смените логин в AD, CRM в своих настройках тоже без пинка ничего менять не будет. С подобной проблемой я сталкивался, когда одна сотрудница вышла замуж и ей на какой-то черт сменили логин. Проблема, тем не менее, заключалась в кривом делигировании авторизации на сервере отчетов (тупо не давал доступ), а не в подлоге безопасности, как в вашем случае! Так что дерзить не стоит: в конце концов это вам нужна помощь, а других желающих ее предоставить я что-то не вижу.
По порядку: вместе с SQL Server устанавливается утилита SQL Profiler, Она позволяет отслеживать все запросы к SQL, в том числе авторизацию и обращение к базе. Возможно она позволит пролить свет на то что творится в вашей среде.
К вопросу о полегчает, в нашей компании OCS не внедрен, однако мне удавалось заставить установленный на мой компьютер коммуникатор почти корректно работать с сервером на виртуалке (только адресная книга не грузилась). При этом корректно работали индикаторы во всех приложениях включая SharePoint, CRM и Outlook, нормально работали отчеты (никто не получал левых данных) и даже индикаторы на кастомных страницах Портала не вызывали чудес описанных вами. Это к вопросу о "сразу полегчает".
По поводу Communicator. Все верно, у OCS есть база где он хранит настройки, вопрос в том, как так получилось, что она хранится на SQL в домене 1, в то время как OCS, очевидно, развернут в домене 2? Office Communication Server очень сложно интегрируется в AD. Изменениям подвергаются как сам каталог, так и лес. Насколько я понимал ситуацию, информация о присутствии при этом хранится непосредственно в AD и никакие данные состояния в базу не пишутся. Иначе я не знаю как объяснить для чего в домене создается больше 50 новых объектов и почему включение расширенных сведений о присутствии при обновлении с 2005 версии, эту настройку уже невозможно отменить. Возможно я и ошибаюсь. Скорее всего ваши админы, как и я, в домене 2, где развернут OCS завели учетки клоны, чтобы имитировать работу в нормальной конфигурации. Вопрос в том, как база попала в рабочий домен, и каким образом и на каком основании в ней авторизуются учетные пользователи из другого домена? Иначе, согласитесь, их логины бы не кешировались

[RegAndrew]

Нет, все немного не так:
OCS установлен в первом домене, в котором находятся отключенные учетки. Кстати они мигрированные, о чем говорит атрибут sidHistory - он указывает на соответствующую учетку во втором домене). Нужно еще разбираться как ведут себя такие записи.
Profiler не особенно помог (кроме времени), тут нужно смотреть лог AD (если есть такой).
Интеграцию хоть и отключил - не помогло.
Пока проблема лечится чисткой соответствующего кэша SQL по факту.
Время ошибки разное, но раз в день, ночью ошибок не было.