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

[RegAndrew]

Не подскажите как отключить интеграцию с Office Communicator в CRM4?
Кроме как в таблице OrganisationBase (поле IsPresenceEnabled) нигде не нашел..
Хотелось бы не так хардкорно

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

Вы идете правильным путем. Через интерфейс эта опция почему-то не настраивается. Ее можно изменить программно, но суть от этого не изменится - смело меняйте в базе.
Нехардкорно можно отключить индикаторы только в представлениях, для этого нужно найти и удалить маленькое поле с email (связанная с контактом или пользователем электронная почта). В лукапах индикатор, насколько я помню, вообще не убирается.
Чем мешает интеграция?

[RegAndrew]

Ситуация такая: есть два домена пусть dm1 и dm2.
CRM находится в первом (оба сервера). Кроме того, есть такая программа - Ofiice Communicator R2.
Для ее работы админы добавляют в первый домен отключенную() учетную запись с таким же именем.
Коммуникатор похоже как-то использует эту учетку. Дальше - больше: при обновлении состояния на формах он пытается сохранить состояние юзера на sql сервере (с учетными данными dm1\user) - лезет на sql под учетными данными dm1\user . Sql все это заботливо кэширует.
И при следующем входе пользователя в CRM под правильными учетными данными dm2\user получаем весьма веселые вещи, когда любая самописная страница отказывается авторизовывать пользователя. Ибо suser_sname, которая лежит в основе авторизации всех FilteredView возвращает dm1\user.
Спасает только рестарт сервиса sql.

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

Боже ж ты мой, кто рассказал вам все эти ужасы? Вопросы приблизительно следующие:
1. И для чего нужны отключенные учетки?
2. Кто вам сказал, что коммуникатор что-то пишет в ваш SQL?
3. И откуда по вашему коммуникатор вообще знает что у вас есть SQL и кто дал ему пароли всех пользователей, чтобы этот вредитель что-то туда писал?
4. Кто дал пользователям CRM права что-то писать в базу (обычно за них это делает системная учетная запись)?
5. Зачем вам два домена?
6. Может быть проблема все же в самописных страницах, если системные ничего не путают, даже не смотря на диверсии коммуникатора?
7. Какого черта вашим страницам, или что-то там у вас, нужно от FilteredView??!! Даже не так... Как вы добились, чтобы авторизация на кастомных страницах происходила при помощи хранимых процедур CRM на уровне SQL сервера??!!

Вы простите мне злую иронию, но я всегда считал что с тремя этими серверными продуктами (CRM, OCS, SQL) я "на ты". Возможно вы докажите мне, что я жестоко заблуждаюсь.

[RegAndrew]

Заранее прошу прощения за сумбурность первого и последующих постов.

1. Без понятия, в администрировании такого плана я уже ниче не понимаю.
2. У него есть своя база на указанном сервере.
3. Видели бы вы меня, когда залогинившись по пользователем "dm2\user" в SSMS и выполнив команду "select suser_sname()", я увидел не "dm2\user", а почему то "dm1\user". Кэш учетных данных в sql это похоже реально (подобная проблема - http://www.sqldev.org/sql-server-sec...me-85741.shtml)
4. Не проверял.
5. Жуткое наследие прошлого
6. К сожалению, в третьей версии все было нормально. Косяк начался именно с 4ой.
7. Самый простой пример - любой отчет RS с параметром, выбирающемся из списка значений полученного из FilteredView. И в этом списке пусто..
Хотя после рестарта, как уже было сказано, список почему-то не пуст.
Часть данных все равно выбирается напрямую (при помощи запросов, не вижу смысла городить огород из fetch-запросов ради простого списка видимых пользователей), пишется же в базу все исключительно при помощи сервиса CRM.

Если нет сомнений в своих знаниях - попробуйте воспроизвести примерчик из ссылки, он не сложный - сразу полегчает

Как можно отследить, когда впервые происходит обращение к серверу sql с некорректными учетными данными?

[Артем 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 по факту.
Время ошибки разное, но раз в день, ночью ошибок не было.

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

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

[RegAndrew]

Совершенно верно, в CRM есть пользователи из разных доменов. Например, одно подразделение из одного, другое из другого.
Тип доверия "лес", отношение доверия двухстороннее. А что вас смущает?

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

Я думал что домены изолированные и вы пользуетесь какой-то извращенной сетевой конфигурацией. CRM поддерживает все возможные режимы домена и леса, OCS более придирчив, но если и его удалось развернуть, то проблема явно не в AD, CRM или OCS. Проблема в каких-то настройках. Вернемся к отключенным (и/или мигрированным) учетным записям. Зачем они нужны, и как они выглядят? У них совпадают логины-пароли?

[RegAndrew]

Нужны или для Exchange или для OCS. Они мигрированные и логин/пароль у них должен совпадать.
Интересно, почему раньше в 3ей версии все было нормально, чем таким они могут отличаться?

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

Совершенно точно могу вам сказать, что ни в OCS ни в Exchange нет такого функционала для которого может потребоваться данное извращение. Уточните у ваших администраторов для чего именно они создаются. Скорее всего проблема именно в этих учетных записях. Я не знаток тонкостей авторизации в windows, однако совершенно точно есть такой вот момент: если вы подключите к вашей сети сторонний компьютер (не включенный в домен) и создадите на нем локальную учетку с логином и паролем совпадающими с вашими доменными, то авторизовавшись под ней вы получите доступ к доменным сетевым ресурсам без повторного запроса логина и пароля. Очевидно, что в данном случае имя домена при аутентификации отбрасывается. А что если у вас таких пользователя два? Сдается мне что тут где-то и притаилась ваша проблема.
Почему это работало в 3.0 - вопрос риторический. Проблема появилась сразу же после обновления? Конфигурация сети, сервера, домена при этом не менялась?

[RegAndrew]

Логон на системе в данном случае еще не означает логон на контроллере.
Ресурсы будут доступны только те, что без соответствующих запретов - например, когда папки для всех расшаривают (тут уж пардон - сами виноваты).
К тому же к IIS7 (на котором CRM) такие учетки не подключатся, анонимная учетная запись отключена. Сразу будет неавторизован. До сиквела по идее не дойдет.

Настройки не менялись.

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

Вы не правы, проведите эксперимент. Мы постоянно пользуемся этим способом для отладки при подключении к тестовым виртуальным машинам, которые не входят в наш домен. На машине создается пользователь с логином и паролем в такими же как в нашем домене и она без проблем позволяет подключаться к своим веб ресурсам без запроса авторизации. Ни о каком гостевом доступе не идет и речи - полноценно отрабатывает NTLM! Пользователь опознан, безопасность работает.

[RegAndrew]

Я правильно понимаю, система считает, что такой пользователь - он как бы тот же самый что и в домене?

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

Не такой же, а буквально тот же!
CRM не обращается к базе от имени пользователя. Для его имперсонации используется context_info, возможно в этом отличие от 3.0. Сейчас этой версии нет под рукой, однако я точно помню, что для получения имени пользователя выполнившего отчет использовалась другая хранимая функция.
Посмотрите следующие посты:
http://www.thuta.info/2010/06/filter...rsonation.html
http://www.thuta.info/2010/08/ifd-wi...nator-and.html
http://purecrm.blogspot.com/2009/10/...in-custom.html
Если вы не переписывали ваши страницы, то я думаю это стоит сделать в соответствии с рекомендациями нового SDK.