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

[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 эти вообще должны резко уезжать на острова и писать книги по опыту установки

[fed]

Цитата:

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

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

Учитывая что заметная часть работы сводится к воспитанию клиентских админов или долгим политическим разводкам с индусами из Микрософтовской поддержки, хочу предложить название позиции "Дресировщик черепах"