Основні попередні вимоги по ПО для установки WM знайдемо в документі Prerequisites (Workflow Manager 1.0).
Обов'язково ознайомиться зі списком додаткових вимог в документі System Requirements (Workflow Manager 1.0). зокрема на SQL сервері при використанні протоколу TCP / IP повинна бути запущена служба SQL Browser.
Весь подальший процес опису буде складатися з такої послідовності дій:
1. Підготовка інфраструктури
Створимо в домені обліковий запис користувача, від імені якої будуть виконуватися служби Workflow Manager. У нашому випадку це буде обліковий запис: s-KOM-AD01-WF-Mgr.
Створимо в домені локальну групу безпеки, яка буде об'єднувати Адміністраторів Workflow Manager, наприклад KOM-AD01-Workflow-Manager-DB-Admins.
Включимо користувача s-KOM-AD01-WF-Mgr в групу KOM-AD01-Workflow-Manager-DB-Admins.
2. Встановлюємо SQL Server Native Client на сервер Workflow Manager
3. Створюємо SQL-Alias на сервері Workflow Manager
Після установки клієнта SQL Server створимо на нашому сервері SQL-Alias. який будемо надалі використовувати для підключення служб Workflow Manager до сервера SQL Server. Цього звичайно можна і не робити, але це може виявитися корисним (дасть нам додаткову гнучкість) в разі необхідності перенесення БД на інший SQL-сервер або навіть екземпляр. Запустимо вбудовану в ОС утиліту SQL Server Client Network Utility (% windir% \ system32 \ cliconfg.exe) і додамо два нових аліаса - з коротким ім'ям SQL-сервера і його FQDN.
При створенні аліаса пам'ятаємо про вимогу в документі Вимоги до системи (Workflow Manager 1.0) виходячи з якого довжина імені не сервера БД повинна перевищувати 15 символів. хоча по суті така вимога справедливо тільки при використанні іменованих каналів (Named pipes) для підключення до SQL Server.
Тепер потрібно перевірити створені нами SQL-аліаси. Для цього створимо порожній файл Universal Data Link з розширенням * .udl і запустимо його. На закладці Connection вкажемо SQL-алиас, виберемо режим аутентифікації Use Windows NT Integrated security і натиснемо кнопку Test Connection
Якщо ми все зробили правильно, то отримаємо позитивний результат підключення. При цьому перелік всіх активних БД на новому SQL сервері буде доступний в випадаючому списку Select the database on the server. Таким чином перевіримо алиас створений як по NetBIOS імені так і по FQDN.
4. Створюємо мережевий кеш Web Platform Installer Offline Cache
Це той список компонент, який може бути встановлений через утиліту Microsoft Web Platform Installer. Якщо безпосередньо з сервера, який ми плануємо використовувати для установки компонент Workflow Manager, немає доступу в Інтернет, то ми можемо, наприклад, на робочій станції адміністратора встановити Microsoft Web Platform Installer і завантажити потрібні нам компоненти, щоб створити комплект для офлайн-установки на сервер . Для зручності загального використання Web Platform Installer в автономному режимі ми створимо окремий мережевий каталог на файловому сервері (\\ holding.com \ Software \ WEB-PI-OFFLINE-CACHE). У цей каталог в подальшому ми завантажимо потрібні нам інсталятори і все їх залежності, організувавши таким чином якийсь загальнодоступний локальний кеш інсталяційних пакетів розповсюджуваних через Web Platform Installer.
Тепер за допомогою встановленого Web Platform Installer нам потрібно завантажити всі вище перераховані компоненти. Зробити це можна як в інтерактивному режимі через UI Web Platform Installer, так і через утиліту командного рядка WebpiCmd.exe. яка за замовчуванням розташована в каталозі установки C: \ Program Files \ Microsoft \ Web Platform Installer
Для початку виконаємо команду перерахування всіх продуктів:
В результаті ми повинні отримати значний список продуктів доступних до установки
Уважно вивчаємо цей список на предмет необхідних нам компонент, щоб дізнатися їх ідентифікатори.
Наступною командою буде виконана завантаження компонент з відповідними ідентифікаторами WorkflowManagerRefresh. WorkflowClient. ServiceBus_1_1 в заздалегідь створений мережевий каталог на файловому сервері, створений для зручності загального використання спеціально під зберігання кешу Web Platform Installer:
У нашому прикладі після завершення процедури завантаження загальний розмір каталогу автономного кешу інсталяторів склав 346MB.
5. Встановлюємо компоненти Workflow Manager на виділений сервер
Після того як офлайн-кеш наповнений потрібними нам інсталяторами, переходимо на сервер, який ми приготували для установки Workflow Manager, встановлюємо на ньому Web Platform Installer і виконуємо команду офлайн установки з кешу (з мережевої папки):
В процесі установки буде включена серверна роль Web Server (встановлені компоненти IIS) і встановлено кілька додатків необхідних для роботи Workflow Manager ...
6. Створюємо ферму Workflow Manager
Відразу після завершення процедури установки буде запущено майстер настройки Workflow Manager Configuration Wizard. Процес установки в різних варіантах повністю описаний в документі Creating a New Farm.
У нашому прикладі вибрано варіант розширеної настройки Configure Workflow Manager with Custom Settings
У формі налаштувань Workflow Manager Configuration в розділі Configure Farm Management Database як SQL Server Instance вкажемо FQDN ім'я SQL-аліаса. який ми створили раніше (KOM-AD01-SQLSP.holding.com).
Включимо опцію Use the above SQL Server instance and settings for all database. щоб використовувати вказане ім'я SQL сервера для всіх інших БД в майстра настройки, і натиснемо кнопку перевірки з'єднання Test Connection
Імена створюваних баз даних Farm Management Database. Instance Management Database. Resource Management Database залишимо запропоновані за замовчуванням.
Як Service Account вкажемо створену раніше доменну обліковий запис s-KOM-AD01-WF-Mgr
Включимо авто-генерацію сертифікатів SSL, необхідних для захисту межкомпонентних з'єднань WM.
Ключ Certificate Generation Key потрібно записати в окреме місце, так як він буде потрібно нам в разі, якщо ми вирішимо розширити ферму Workflow Manager додатковим сервером.
Значення використовуваних WM портів залишаємо за замовчуванням - 12290 і 12291. Для цих портів будуть автоматично створені дозвільні правила в Windows Firewall за умови, що включена опція Enable firewall rules on this computer.
Включаємо опцію, що дозволяє WM незахищені з'єднання HTTP - Allow Workflow management over HTTP on this computer
У параметрі Configure Admin Group замінюємо встановлений за умовчанням значення BUILTIN \ Administrators на ім'я створеної нами раніше групи безпеки KOM \ KOM-AD01-Workflow-Manager-DB-Admins
Кнопкою стрілки переходимо до другого етапу настройки - Service Bus Configuration.
Ім'я сервера SQL і баз даних Farm Management Database. Gateway Database і Message Container Database залишаємо запропоновані за замовчуванням, перевіряючи можливість їх подальшого створення за допомогою кнопок Test Connection
Як Service Account будемо використовувати ту ж саму обліковий запис, що використовували для WM включивши опцію Use the same service account credentials as provided for Workflow Manager
Так само як і для WM включимо авто-генерацію сертифікатів (Auto-generate) і використовуємо той же Certificate Generation Key - Use the same certificate generation key as provided for Workflow Manager.
Порти залишаємо в значеннях за замовчуванням. Для них з включеною опцією Enable firewall rules on this computer також автоматично будуть створені дозвільні правила в брандмауері Windows.
У параметрі Configure Admin Group вкажемо ім'я створеної нами раніше групи безпеки KOM \ KOM-AD01-Workflow-Manager-DB-Admins
На екрані Summary ще раз перевіряємо всі встановлені установки і натискаємо кнопку конфігурації в нижньому правому куті ...
Чекаємо закінчення процесу конфігурації ...
Після успішного закінчення установки переконуємося в тому, що в Windows Firewall створені дозвільні правила для вхідних підключень як було визначено в Workflow Manager Configuration Wizard.
На SQL сервері перевіряємо створені БД і при необхідності міняємо для них Recovery model з встановленого за замовчуванням Full на Simple.
Register-SPWorkflowService. The caller does not have the necessary permissions required for this operation. Permissions granted: None. Required permissions: WriteScope. HTTP headers received from the server - ActivityId: 96af3802-0e68-4c35-9105-2038b5a44417. NodeId: WFM-Server. Scope: / SharePoint. Client ActivityId. 484bf3d4-9334-43e0-83a3-fd522ddb390d.
Причиною цієї помилки стало те, що я забув включити свою облікову адміністративну запис, від імені якої виконувалася команда, в групу адміністраторів WFM (в нашому випадку це група KOM-AD01-Workflow-Manager-DB-Admins).
Додаткові джерела інформації.
Дякую за посилання, я цю тему вже вивчав. Тільки не можу зрозуміти одне. Якщо у мене кілька сімейств веб-сайтів, і я вкажу лише одне, то чи будуть працювати процеси workflow на інших родинах? Або для інших сімейств потрібні повторні команди?
Наприклад. Є веб-додаток «work.lan» в ньому кілька семества \, \ buh, \ manager. Якщо я вкажу сімейство work.lan чи працюватиме на work.lan \ buh? Адже з головного сімейства не передаються права у спадщину на інші сімейства, ось і виникає питання по worflow.
Десь я читав, що в параметр -SPSite можна вказати посилання на будь-який сімейство сайтів.
Причому Workflow Service буде доступний на рівні всієї ферми.
Грубо кажучи командлет Register-SPWorkflowService чіпляє Workflow Manager до всієї фермі, а не до конкретного сімейства сайтів.
Є ідеї, що ще не вистачає.
Дякуємо.