CRM Update, лекция о вреде синтетических галлюциногенов и психотропных средств.

С тех пор как я стал профессионально заниматься продуктами Microsoft, я задаюсь рядом вопросов относительно ее решений. Если привести их к общему знаменателю, то он звучал бы как: "они это специально, или само так выходит?". И вот одним таким частным вопросом является вопрос установки обновлений ПО этой фирмы. Ответьте мне кто-нибудь, почему до сих пор нет и не предвидится единого стандарта? Ведь умеют как-то автоматом обновляться Windows, Office, .NET, IE, Silverlight, еще кто-то там... Почему путь обновления доморощенного продукта CRM 4.0 состоит из не очевидных 9 этапов?
Схематично я бы обозначил его следующим образом:

exe -> xml -> cmd -> database -> outlook -> regedit -> internet/intranet site -> update -> suicide.

Шаг первый: exe
Во-первых MS никогда не выкладывает обновленные дистрибутивы своих продуктов, как это принято в том же OpenSource. В результате даже для "чистой" установки, мы должны как-то нахлабучить заведомо глючный дистрибутив в систему, после чего его пропатчить. Во-вторых, ни одно приложение не умеет автоматически обновляться через интернет! Это всегда происходит через такую-то матерь... И, наконец, конкретно для CRM обновления доступны как исполняемые приложения exe а не msi. Это я к тому, что через групповые политики и прочие примочки их не установить.

Шаг второй: XML
Теперь мы должны распотрошить exe в командной строке и достать из него XML с параметрами обновления. Интересный момент: помимо всего прочего из него вывалится msi пакет, но он не умеет устанавливаться сам или через GP. Далее, вооружившись patch id, мы должны нарисовать другой XML, в котором напишем пользователю о том, зачем нужно это обновление, или может даже обяжем его установить этот патч. Замечу, что структура этого файла настолько наворочена, что при наличии должного терпения и желания мы можем задать любые ограничения на установку конкретного патча: версия офис и клиента, языковая версия дистрибутива, предварительная установка другого патча и т. д. И все для чего? Для того, чтобы перейти на следующий этап.

Шаг третий: cmd
И вот теперь, когда у нас есть сам файл патча и файл настроек, самое время бы приступить к его установке? Зачем же так просто?! Теперь мы запустим КОНСОЛЬНОЕ приложение Microsoft.Crm.Tools.ClientPatchConfigurator.exe, которое что? Зарегистрирует нашу XML в базу данных CRM системы!!! А как же будем ставить? - спросите вы. А куда торопиться? - отвечу я вам, переходим на следующий шаг.

Шаг четвертый: database
Данные из XML конфига путем вызова описанной выше утилиты попадают в базу MSCRM_CONFIG, где они хранятся в нестройном ряде из 6 таблиц. Записи из XML могут добавлять в базу или изменять информацию по доступным патчам при помощи тега <Create>, или удалять лишние патчи из базы с помощью тега <Delete> . При этом, единственным инструментом для просмотра текущей конфигурации обновления остается сам клиент Outlook, а точнее утилита Update, которая теперь входит в комплект.

Шаг пятый: Outlook
Далее эстафету принимает CRM Client for Outlook AutoUpdate (Microsoft.Crm.Client.AutoUpdate.exe). При подключении к серверу программа получает информацию о наличии обновлений и, в зависимости от настроек, может установить их самостоятельно (если клиент запускается с ключом /Q) или заставить пользователя их установить (если на этапе настройки обновление было помечено как <IsMandatory>). Утилита имеет свой собственный шеддуллер и по умолчанию стартует раз в 4 часа. Так же существует возможность запускать ее с параметрами из командной строки. Для этого ей потребуется свой собственный XML конфг. Параметры системы обновлений задаются для каждого пользователя по отдельности, но не на сервере, как и в случае с настройками синхронизации, а на клиенте! Притом через реестр Windows.

Шаг шестой: regedit
По неясным для меня причинам, пользовательские настройки системы обновлений не хранятся в базе CRM и не доступны через интерфейс системы. Вместо этого они настраиваются для каждой клиентской машины. В базе же хранится только информация вида "Внимание есть апдейт!". Далее следует этап загрузки обновления с сайта: http://go.microsoft.com/fwlink/?LinkId=<PathID>. Вот этот шаг понятен мне меньше всего. Почему именно сейчас загрузка идет через интернет? Мы же уже уйму всякой всячины на стороне сервера настроили? Ну, вот так... Если мы хотим, чтобы загрузка происходила из локального каталога нужно прописать его путь в реестре в ветке HKEY_LOCAL_MACHINE\Software\Microsoft\MSCRMClient\AutoUpdateDownloadUrl. Для каждой машины по отдельности!!! Vivat централизованному хранению информации!

Шаг седьмой: internet/intranet site
Если заказчик (или здравый смысл) против того, чтобы с каждого компьютера выкачивалось 27МБ трафика для установки каждого обновления, вам следует настроить локальный каталог для размещения апдейтов. Каталога, впрочем, не достаточно. Дело в том, что апдейты будут выкачиваться по http/ftp, так что нужно будет создать виртуальный каталог на IIS, например, под существующим сайтом CRM, куда и выкладывать файлы обновлений. Можно создать для этой цели и отдельный сайт, но тогда возникает риск дополнительного геморроя в конфигурации IFD.

Шаг восьмой: update
И вот, ура-ура, выжившие могут, наконец, перейти на следующий шаг: установка обновлений! И вот тут в очередной раз хочется закричать "выкуси"... Для выполнения установки нужны права локального администратора!!! Да да да, внимательный читать может поймать меня за руку и сказать: "Уже нет! С выходом Update Rollup 7 систему обновлений были внесены существенные изменения! Теперь для выполнения этой операции не нужны расширенные права!". Вы совершенно правы, но как, простите, вы будете ставить сам седьмой пакет обновлений? Дело в том, что сам седьмой пакет требует установки патчей на Windows (WinInstaller 4,5) и является необходимым для установки всех последующих апдейтов! Теперь становится ясно, для чего нужны были все эти параметры в XML конфиге на предыдущих шагах, правда? Учитывая что у нас нет "чистого" дистрибутива с внедренным UR7, который мы могли бы централизованно разворачивать через GPO, административные права по прежнему являются лимитирующим требованием для установки.

Шаг 9: suicide
Вот теперь выживших, думаю, нет. Любой админ заказчика получив от вас такую инструкцию спросит: "Что вы там у себя курите, многоуважаемые интеграторы?" (не без мата, разумеется), после чего ваша система обновлений почти наверняка будет выглядеть как сетевая шара \\crm\crmclientupdates. В лучшем вы сделаете ее видимой только для CRMUserGroup и на этом все высокие технологии закончатся.

Дополняет высокохудожественную картину маразма введенная все в том же Update Rollup 7 опция веб установки CRM клиента. С момента выхода системы обновлений, появившейся в Update Rollup 4, разработчики проделали огромную работу и существенно улучшили "usability" сократив количество операций с 9 до 5:

exe -> regedit -> internet/network share -> XML -> suicide

Шаг первый: exe
Первая проблема - это увидеть сам линк на установку. На IE 6 и 7 при отсутствии доступа в интернет вы можете ожидать загрузки сайта до 40 секунд. Решение кроется в неком туманном шаманстве: http://support.microsoft.com/default.aspx/kb/2005056. ИМХО, достаточно странная плата за лишний линк на файл.

По умолчанию линк на установку выкачивает не сам клиент, а утилиту ClientInstaller.exe, которая качает сам клиент... Откуда? Верно из интернет! Ну или вы, конечно, можете ее настроить!

Шаг второй: regedit
Вы могли подумать, что логично использовать уже существующие ключи реестра, ан нет! Нужен новый HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\MSCRMClient\InstallerUrl. Данный ключ должен указывать на дистрибутив для установки клиента.

Шаг третий: internet/network share
В отличии от своего старшего брата AutoUpdateDownloadUrl, InstallerUrl должен указывать на прямой сетевой адрес типа \\crm\clientinstall\CRMV4.0-I386-Client-RUS.exe, так что сражаться с IIS не придется... Ну, если у вас не IFD.

Шаг четвертый: XML
Данный шаг - проблема не столько веб инсталлятора, сколько инсталлятора обычного. Отчего-то нельзя вложить конфиг для установки клиента в пакет с дистрибутивом. Default_Client_Config.xml должен лежать в каталоге C:\Users\username\AppData\Roaming\Microsoft\MSCRM на каждом клиентском компьютере. Как его туда засунуть - думайте сами.

Шаг пятый: suicide
Если не было выполнено требование предыдущего шага установка клиента будет беспомощной - нужно будет настраивать клиент вручную, иначе он не сможет ни подключиться к системе, ни обновиться. Обидно, но service discovery в CRM так и не появился. Тот же Microsoft Office Communicator (клиент для OCS Server) давно умеет находить "мамку" по записи DNS SRV (Запись типа Service Location на DNS сервере). Куда хуже тот факт, что данный жалкий аналог веб исталлятора по-прежнему требует наличия прав локального администратора. Часто это обозначает конец установки и сводит на нет все предыдущие приготовления. Лично я не пробовал указывать в качестве каталога для установки шару используемую при создании GPO инсталляции. Думаю что в этом случае административный дистрибутив так же должен отработать нормально.

Подводя итог всего вышеописанного, я задаюсь вопросом, почему люди которые решили сложнейшие задачи создания оффлайн клиента, расширяемой xRM платформы и развитой подсистемы асинхронных операций, не справились с тривиальной задачей автообновления клиента и создали ТАКОЕ чудовищное убожество?