Показать сообщение отдельно
Старый 26.06.2018, 00:18   #1  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,592 / 5222 (182) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 2
Cool D365FO on-premises - опыт установки
Хотя в поддержке Microsoft и утверждают, что с горки с попутным ветром D365FO on-premises ставится за 4 часа, но мне лично установка стоила трех недель работы без выходных
Нажмите на изображение для увеличения
Название: D365O-LCS-deployment-details-v2.png
Просмотров: 393
Размер:	28.7 Кб
ID:	11964
С датой небольшая неточность - это начало установки, которая завершилась с энной попытки много дней спустя. При этом собственно запуску установки предшествовала долгая работа по подготовке окружения и развертыванию на нем 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 в чем-то напоминает постройку жилого дома - только роботами и где-нибудь на луне. Если при постройке обычного жилого дома выясняется, что недостает цемента или пары оконных рам, то их тупо заказывают, довозят и продолжают стройку, почти не сбавляя темпа. Тут же ситуация иная: долго готовится экспедиция, снаряжается ракета, собираются все необходимые грузы, настраиваются строительные роботы, затем - старт и томительное ожидание. Приземлилась ракета, выгрузились роботы, начали строить по заранее заданной программе, но если вдруг выяснилось, что для постройки не хватает пары оконных рам, то варианта "подвезти и продолжить" нет. Приходится экстренно прекращать лунную экспедицию, сносить всю постройку до фундамента, снаряжать новую ракету, докладывать в нее недостающие рамы, заново готовить и запускать ракету на луну - и уповать на то, что перед стартом всё было проверено, а то в конце выяснится, что коды доступа у тех роботов, что строят чердак, не совпадут с кодами доступа у тех роботов, что строят жилые этажи, в итоге одни других не допустят к работе, стройка встанет, и придется снаряжать новую экспедицию...

Последний раз редактировалось gl00mie; 26.06.2018 в 00:22.
За это сообщение автора поблагодарили: trud (10), sukhanchik (15), Logger (61), AlexeyS (8), Ivanhoe (10), oip (5), fed (10), Link (9), Vadik (1), raz (20), AlGol (3), ax_mct (7), vmoskalenko (1), Poleax (10), alex55 (3), altap (1).