D365FO on-premises - опыт установки

[gl00mie]

Хотя в поддержке Microsoft и утверждают, что с горки с попутным ветром D365FO on-premises ставится за 4 часа, но мне лично установка стоила трех недель работы без выходных

С датой небольшая неточность - это начало установки, которая завершилась с энной попытки много дней спустя. При этом собственно запуску установки предшествовала долгая работа по подготовке окружения и развертыванию на нем Service Fabric.

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

Еще весело было из-за PowerShell-скриптов и разных особенностей их работы. Так, например, в некоторые скрипты прописано название группы Administrators, а мне достались сервера с русскими виндами, где аналогичная группа называется Администраторы. Установочные скрипты не были рассчитаны на такой фортель и сыпали ошибками при проверке наличия прав доступа. Отсюда мораль: лучше использовать англоязычные Windows, потому как и проблем меньше, и тексты ошибок, в случае чего, проще в интернете найти.

Также не обошлось без курьезов в том, как задавать учетки в настройках. У виндового домена есть два имени:

• DNS-ное - два и более слова, разделенных точкой, например, MyDomain.local; для справки, служба DNS используется в доменах Windows, начиная с W2K, т.е. уже почти 20 лет
• NetBIOS-ное - одно слово до 15 символов, пишется заглавными буквами, например MYDOMAIN; по большому счету это - пережиток времен NT4 и Win95

При этом теоретически NetBIOS-ное и DNS-имя домена могут существенно отличаться. Так вот, в конфигурационном файле разного рода служебные учетки можно задать так и эдак, с помощью NetBIOS-ного и DNS-имени домена - винды при настройке всё поймут. Но вот проверочные PowerShell-скрипты поймут отнюдь не всё: они сравнивают строки описаний прав доступа, скажем, к закрытым ключам сертификатов, со строками названий учетных записей из своих настроек (регистронезависимо - и на том спасибо). При этом всякие PowerShell-cmdlet-ы возвращают настройки доступа в строковом представлении с использованием именно NetBIOS-имен доменов, например, MYDOMAIN\AXDBAdmin. Так вот, если в конфигурационном файле использовалась другая форма записи, то вас ждут проваленные проверки тестовых скриптов установки. А пропускать эти проверки страшно - потом ведь начнет валиться на ровном месте, и пойди, расковыряй, что какой-то сервисной учетке прав не хватает.

Вообще, установка D365O on-premises в чем-то напоминает постройку жилого дома - только роботами и где-нибудь на луне. Если при постройке обычного жилого дома выясняется, что недостает цемента или пары оконных рам, то их тупо заказывают, довозят и продолжают стройку, почти не сбавляя темпа. Тут же ситуация иная: долго готовится экспедиция, снаряжается ракета, собираются все необходимые грузы, настраиваются строительные роботы, затем - старт и томительное ожидание. Приземлилась ракета, выгрузились роботы, начали строить по заранее заданной программе, но если вдруг выяснилось, что для постройки не хватает пары оконных рам, то варианта "подвезти и продолжить" нет. Приходится экстренно прекращать лунную экспедицию, сносить всю постройку до фундамента, снаряжать новую ракету, докладывать в нее недостающие рамы, заново готовить и запускать ракету на луну - и уповать на то, что перед стартом всё было проверено, а то в конце выяснится, что коды доступа у тех роботов, что строят чердак, не совпадут с кодами доступа у тех роботов, что строят жилые этажи, в итоге одни других не допустят к работе, стройка встанет, и придется снаряжать новую экспедицию...

[trud]

Поздравляю. А насколько вообще оперативно реагировала поддержка MS на возникающие вопросы?
PS: не узнавал случаем, не рассылают ли они майки - "Я установил D365 OnPrem" тем кто прошел квест?

[fed]

Могу добавить, что MS вообще не сделала никакой обработки ошибки во многих частях логики инсталляторов On Premises. Например, у нас долго не проходила установка Management Reporter (причем, конечно же, без какой-либо внятной диагностики). В последствии по косвенным признакам (ругани в логах от какого-то другого софта), я заметил что у нас посыпалась база performance counters. После того как я ее перестроил, установка MR запустилась. То есть, при более или менее нормальной разработке, надо было бы проверить коды ошибок при попытке инициализации performance counters, выдать сообщение и продолжить установку (в конце концов - можно жить без этих счетчиков долбанных). Но у них там похоже что просто было написано if(errNo) exit(255) И везде у них такая обработка ошибок.

[Ivanhoe]

Цитата:

Сообщение от fed

Например, у нас долго не проходила установка Management Reporter (причем, конечно же, без какой-либо внятной диагностики)

Сорри, что в сторону, а в D365 от него разве не отказались?

[fed]

Цитата:

Сообщение от Ivanhoe

Сорри, что в сторону, а в D365 от него разве не отказались?

Пока нет. Учитывая что PowerBI On Premises пока не поддержали (и я даже слухов о таковой поддержке не слышал), я все сильнее сомневаюсь что они смогут быстро на powerBI перейти с MR.

[trud]

Цитата:

Сообщение от Ivanhoe

Сорри, что в сторону, а в D365 от него разве не отказались?

Его переименовали в Financial reporting, но собственно программа выглядит так-же

https://www.sherweb.com/blog/managem...for-operation/

[fed]

Цитата:

Сообщение от trud

Его переименовали в Financial reporting, но собственно программа выглядит так-же

https://www.sherweb.com/blog/managem...for-operation/

Но вообще ходили какие-то разговоры про то чтобы MR заменить на что-то powerBI based..

[Ivanhoe]

Типа вот этого: https://community.dynamics.com/365/f...ter-eventually

Financial reporting, получается, настраивается и смотрится "изнутри" Аксапты, но по сути - внешний отдельный компонент, раз нужно отдельно ставить?

[cuba]

Цитата:

Сообщение от Ivanhoe

Типа вот этого: https://community.dynamics.com/365/f...ter-eventually

Financial reporting, получается, настраивается и смотрится "изнутри" Аксапты, но по сути - внешний отдельный компонент, раз нужно отдельно ставить?

Типа того)

[Ivanhoe]

Цитата:

Сообщение от gl00mie

Хотя в поддержке Microsoft и утверждают, что с горки с попутным ветром D365FO on-premises ставится за 4 часа, но мне лично установка стоила трех недель работы без выходных

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

[fed]

Цитата:

Сообщение от Ivanhoe

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

По личному - опыту - это ОЧЕНЬ зависит от кривизны клиентского окружения и вменяемости админов. Я бы сказал - собственно консалтерских усилий по установке - где-то порядка 15-20 человекодней. Вопрос в том, если что-то в окружении (например в ADFS или в доменных структурах) криво - как заставить клиента это подправить. У нас на первой установке что-то кривило в AD и сервер периодически переставал видеть куски AD. После 3-4 дней экспериментов, удалось найти команду PowerShell, которая в случае глюков выдавала неправильные результаты. Я эту команду показал клиентским админам и попросил исправить. В итоге - они недели три исправляли ситуацию путем перезагрузки серверов. (После чего все работало день-полтора и потом снова начинало глючить). В итоге у меня ушло недели три на то чтобы их продавить на настоящую починку (которая в итоге свелась к переустановке нескольких серверов с ноля).
Просто там проблема в том, что требования к качеству настройки инфраструктуры достаточно высоки. Попытки клиентским админам указать на кривизну, приводят к ответу "У нас все работает" (Просто иногда виснет, пегружается и глючит - но в принципе в рамках допустимого для типичной установки Windows).
P.S. У второго клиента тоже что-то подобное было. Там клиент около недели пытался переводить стрелки на нас, указывая на то что мы должны сами настроить их инфраструктуру. Я примерно день извел на написание ехидных писем на эту тему. Потом они внезапно нашли причину своих проблем с ADFS и быстренько и без наездов ее исправили. (так что я даже забыл про эти разборки)

[Vadik]

Вспоминаю недавние охания в стиле "а вдруг там индусы в Azure что-то поломают, а в on prem мы завсегда сами все быстро починим". Чотаржу (с)

[fed]

Цитата:

Сообщение от Vadik

Вспоминаю недавние охания в стиле "а вдруг там индусы в Azure что-то поломают, а в on prem мы завсегда сами все быстро починим". Чотаржу (с)

Знаешь - это скорее о кривизне дизайна системы говорит, а не о проблемах On Premises. По большому счету - единственное полезное новшество D365 - это новый модуль учета затрат (кстати разработанный еще во времена DAX2012R1). И если без увеличения полезной для клиентов функциональности, так сильно выросли затраты на администрирование - это очень о многом говорит. Может Аксапту в Azure перенесли только для того чтобы повысить занятость в Бенгалору и Хайдарабаде ?

[AlexeyS]

Сложность системы начинает переходить некие разумные границы. Интересно, у других схожая ситуация?

[cuba]

Цитата:

Сообщение от fed

Знаешь - это скорее о кривизне дизайна системы говорит, а не о проблемах On Premises. По большому счету - единственное полезное новшество D365 - это новый модуль учета затрат (кстати разработанный еще во времена DAX2012R1). И если без увеличения полезной для клиентов функциональности, так сильно выросли затраты на администрирование - это очень о многом говорит. Может Аксапту в Azure перенесли только для того чтобы повысить занятость в Бенгалору и Хайдарабаде ?

Извините, что в не в тему, но что это за модуль такой?
Есть модуль Учет затрат существующий еще с 4-ки, по-моему.
В D365 добавили модуль по затратам. Но я бы не назвал его новым, просто он собрал в себе все, скажем так, MenuItems из других модулей (Производства, запасов и т.д.).
Вы же о нем писали?

[Ivanhoe]

Цитата:

Сообщение от fed

По личному - опыту - это ОЧЕНЬ зависит от кривизны клиентского окружения и вменяемости админов. Я бы сказал - собственно консалтерских усилий по установке - где-то порядка 15-20 человекодней.

Это очень много, на порядок, получается, больше AX 2012. Мда.

[vmoskalenko]

Цитата:

Сообщение от fed

Потом они внезапно нашли причину своих проблем с ADFS и быстренько и без наездов ее исправили. (так что я даже забыл про эти разборки)

Я так думаю, что проще свой собственный ADFS поднимать.
Тем более что для каждого энвайронмента (UAT, PROD) требуется свой собственный ADFS
Microsoft грозился сделать возможность использовать один ADFS, во всяком случае зимой было именно так.

[gl00mie]

Цитата:

Сообщение от fed

Цитата:

Сообщение от Ivanhoe

В следующий раз на новом окружении примерно сколько времени будет запланировано на "продумать весь план, пропатчить роботов и положить запасные деталюшки" и непосредственно на сам проект "полететь, построить, сдать"?

Я бы сказал - собственно консалтерских усилий по установке - где-то порядка 15-20 человекодней.

Календарного времени я бы закладывал минимум 4-5 недель. Тут еще дело в том, что для on-premises нужно две схожие среды: собственно рабочая и аналогичная среда sandbox, на которой будет обкатываться успешность установки обновлений и модификаций. Просто так по-ковбойски накатывать что-то сразу на рабочую среду LCS не дает, мол, сначала убедитесь, что оно в песочнице хотя бы установится без ошибок. И тупо одним сервером UAT всё-в-одном уже не обойтись, так что "песочницу" лучше развернуть как можно раньше.
Надо еще понимать, что для установки AX2012 и D365FO on-premises нужны разные навыки и, возможно, разные люди. Если 12-ку может поставить разработчик, который прочитал наскоро тренинг по администрированию и знает, чем доменная учетка отличается от Network Service, то в случае с D365FO on-premises нужно будет настраивать:

• DNS (создавать новые зоны и A-записи, возможно, alias'ы для существующих серверов)
• AAD (Azure Active Directory)
• ADFS (скорее всего, ставить с нуля)
• Azure Service Fabric (ставить с нуля)
• Firewall (публиковать порты наружу)
• SQL Server в кластере или AlwaysOn
• Certification Authority в домене (из коробки он, вероятно, не станет генерить то, что вам надо)

При всем этом надо будет разбираться в том, как генерировать сертификаты (это отдельная песня!) и раздавать права на их закрытый ключ, активно использовать PowerShell, вероятно, ProcMon и PerfView для ловли трассировок, какой-нибудь ILSpy для анализа кода сборок установщиков и сервисов, которые валятся в ошибку... В общем, это работа скорее для сисадмина, а не разработчика.

[AlexeyS]

Один чел мне недавно сказал, что работа в 365fo больше связана не с разработкой, а с решением проблем клиентов.

[ax_mct]

Цитата:

Сообщение от AlexeyS

Один чел мне недавно сказал, что работа в 365fo больше связана не с разработкой, а с решением проблем клиентов.

То есть другими словами, услуги по разработке в D365FO на порядок меньше востребованы чем в AX, но услуги support (без кастомизаций) наоборот на порядок больше.

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

Даже не знаю как их назвать. Наладчики, что-ли. Специалисты по закручиванию хобота в посудной лавке. А on-premise эти вообще должны резко уезжать на острова и писать книги по опыту установки