В рамках внедрения одного локального проекта разработанного под SharePoint Server 2013 возникла необходимость развернуть выделенный сервер под экземпляр Workflow Manager 1.0 (WM) для его последующей интеграции в SharePoint Server. Рассмотрим пошагово процесс реализации этой задачи.
Для начала ознакомимся с документом Install and configure workflow for SharePoint Server 2013, который в свою очередь отправит нас к документу Installing and Configuring Workflow Manager 1.0.
Список поддерживаемых платформ найдём в документе Supported Platforms (Workflow Manager 1.0). Отталкиваясь от этого списка и потребностей нашей задачи для будущего выделенного сервера WM создадим виртуальную машину Hyper-V G2 с гостевой ОС Windows Server 2012 R2 Standard EN и аппаратной конфигурацией - 4 vCPU, 4 GB RAM (Static), 40 GB vHD (Dynamic).
В качестве сервера БД для создаваемых баз данных Workflow Manager в нашем случае будет использоваться уже созданный ранее удалённый кластеризованный экземпляр SQL Server 2012 SP1, который уже используется для баз SharePoint Server 2013.
Основные предварительные требования по ПО для установки WM найдём в документе Prerequisites (Workflow Manager 1.0):
1. .NET Framework 4 с обновлением платформы 3 (PU3) или .NET Framework 4.5
2. PowerShell 3.0
3. Service Bus 1.0
4. Workflow Client 1.0
Компоненты 1 (.NET Framework 4.5) и 2 (PowerShell 3.0) установлены и активированы в Windows Server 2012 R2 по умолчанию. Компоненты 3 и 4 будут установлены в процессе установки WM. Поэтому в процессе установки желательно иметь подключение к Интернет. Если подключение сервера к Интернет по каким-то причинам невозможно, то можно воспользоваться процедурой офлайн-установки описанной в статье Offline Installation Instructions for Workflow Manager 1.0
Обязательно ознакомится со списком дополнительных требований в документе System Requirements (Workflow Manager 1.0), в частности на SQL сервере при использовании протокола TCP/IP должна быть запущена служба SQL Browser.
Весь последующий процесс описания будет состоять из следующей последовательности действий:
1. Подготовка инфраструктуры
2. Устанавливаем SQL Server Native Client на сервер Workflow Manager
3. Создаем SQL-Alias на сервере Workflow Manager
4. Создаем сетевой кэш Web Platform Installer Offline Cache
5. Устанавливаем компоненты Workflow Manager на выделенный сервер
6. Создаём ферму Workflow Manager
7. Устанавливаем клиент Workflow Client 1.0 на WFE-серверы SharePoint 2013
8. Регистрируем Workflow Manager 1.0 в ферме SharePoint 2013
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
Так как базы данных Workflow Manager в нашем случае будут расположены на удалённом экземпляре SQL Server 2012 SP1 (CU9), перед началом установки Workflow Manager на наш выделенный сервер нужно установить пакет Microsoft SQL Server Native Client. Его можно загрузить например со страницы Microsoft SQL Server 2012 SP1 Feature Pack (файл ENU\x64\sqlncli.msi), а ещё лучше взять дистрибутив клиента обновлённой версии из состава последнего обновления - CU9 (файл \SQLServer2012_SP1_CU9\1033_enu_lp\x64\setup\x64\sqlncli.msi)
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
В нашем примере нужно установить все необходимые компоненты для работы Workflow Manager 1.0 CU2 в связке с SharePoint Server 2013 SP1, а именно:
Workflow Manager 1.0 Refresh (уровень обновления CU2 от 31.01.2014)
Workflow Manager Client 1.0 Refresh (уровень обновления CU2 от 31.01.2014)
Windows Azure Pack: Service Bus 1.1 (от 18.10.2013)
Это тот список компонент, который может быть установлен через утилиту Microsoft Web Platform Installer. Если непосредственно с сервера, который мы планируем использовать для установки компонент Workflow Manager, нет доступа в Интернет, то мы можем, например, на рабочей станции администратора установить Microsoft Web Platform Installer и загрузить нужные нам компоненты, чтобы создать комплект для офлайн-установки на сервер. Для удобства общего использования Web Platform Installer в автономном режиме мы создадим отдельный сетевой каталог на файловом сервере (\\holding.com\Software\WEB-PI-OFFLINE-CACHE). В этот каталог в дальнейшем мы загрузим нужные нам инсталляторы и все их зависимости, организовав таким образом некий общедоступный локальный кэш инсталляционных пакетов распространяемых через Web Platform Installer.
Итак, на рабочей станции администратора, загружаем Microsoft Web Platform Installer 4.6 (файл wpilauncher.exe размером 113KB) и запускаем его с правами администратора имеющего доступ в Интернет. Если по какой-то причине онлайн-инсталлятор не смог загрузить полный пакет для установки из Интернет, то можно самостоятельно загрузить офлайн-инсталлятор по ссылке https://go.microsoft.com/?linkid=9737537 (файл WebPlatformInstaller_amd64_en-US.msi размером 1.56MB) и выполнить его установку (опять же из командной строки с правами администратора)
Теперь с помощью установленного Web Platform Installer нам нужно загрузить все выше перечисленные компоненты. Сделать это можно как в интерактивном режиме через UI Web Platform Installer, так и через утилиту командной строки WebpiCmd.exe, которая по умолчанию расположена в каталоге установки C:\Program Files\Microsoft\Web Platform Installer
Для начала выполним команду перечисления всех продуктов:
cd /d "C:\Program Files\Microsoft\Web Platform Installer" WebPiCmd /List /ListOption:All
В результате мы должны получить внушительный список продуктов доступных к установке
Внимательно изучаем этот список на предмет необходимых нам компонент, чтобы узнать их идентификаторы.
Следующей командой будет выполнена загрузка компонент с соответствующими идентификаторами WorkflowManagerRefresh, WorkflowClient, ServiceBus_1_1 в заранее созданный сетевой каталог на файловом сервере, созданный для удобства общего использования специально под хранение кэша Web Platform Installer:
WebPiCmd /Offline /Products:"WorkflowManagerRefresh,WorkflowClient,ServiceBus_1_1" /Path:\\holding.com\Software\WEB-PI-OFFLINE-CACHE
В нашем примере по завершению процедуры загрузки общий размер каталога автономного кэша инсталляторов составил 346MB.
5. Устанавливаем компоненты Workflow Manager на выделенный сервер
После того как офлайн-кэш наполнен нужными нам инсталляторами, переходим на сервер, который мы приготовили для установки Workflow Manager, устанавливаем на нём Web Platform Installer и выполняем команду офлайн установки из кэша (из сетевой папки):
cd /d "C:\Program Files\Microsoft\Web Platform Installer" WebPiCmd /Install /Products:"WorkflowClient,ServiceBus_1_1,WorkflowManagerRefresh" /XML:"\\holding.com\Software\WEB-PI-OFFLINE-CACHE\feeds\Latest\webproductlist.xml" /Log:"C:\Web-Platform-Installer-Log.txt" /AcceptEula
В процессе установки будет включена серверная роль 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.
Проверяем доступность Workflow Manager с сервера SharePoint открыв на нём в Internet Explorer (запускать с правами Администратора и с отключенными настройками прокси) ссылку
http://WFM-Server.holding.com:12291
7. Устанавливаем клиент Workflow Client 1.0 на WFE-серверы SharePoint 2013
Переходим на сервер SharePoint Server 2013, устанавливаем на нём Web Platform Installer и выполняем команду офлайн установки клиента Workflow Client 1.0 из кэша:
cd /d "C:\Program Files\Microsoft\Web Platform Installer" WebPiCmd /Install /Products:"WorkflowClient" /XML:"\\holding.com\Software\WEB-PI-OFFLINE-CACHE\feeds\Latest\webproductlist.xml" /Log:"C:\Web-Platform-Installer-Log.txt" /AcceptEula
8. Регистрируем Workflow Manager 1.0 в ферме SharePoint 2013
Согласно ранее обозначенного документа перед началом интеграции и последующим использованием рабочих процессов Workflow Manager в нашей ферме SharePoint Server 2013 уже должна быть установлена и сконфигурирована Служба профилей (User Profile Service).
Запускаем от имени администратора SharePoint 2013 Management Shell либо в Windows PowerShell предварительно подгрузив PSSnapin SharePoint выполняем:
Add-PSSnapin Microsoft.SharePoint.PowerShell Register-SPWorkflowService –SPSite "http://SP-Server.holding.com" –WorkflowHostUri "http://WFM-Server.holding.com:12291" –AllowOAuthHttp
Если по какой-то причине при выполнении команды регистрации произошла ошибка, то можно посмотреть заметку Least Privilege Configuration for Workflow Manager with SharePoint 2013. В своём случае я получил ошибку:
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).
Результат регистрации WFM в ферме SharePoint можно проверить например на веб-узле Центра администрирования по ссылкам: Central Administration > Application Management > Service Applications - Manage service applications в списке служб должна появится Workflow Service Application Proxy. При её открытии мы должны увидеть статус Connected
***
На этом процесс установки и настройки Workflow Manager 1.0 CU2 с последующей интеграцией с SharePoint Server 2013 SP1 можно считать оконченным.
Дополнительные источники информации:
- Workflow Manager Farms for SharePoint 2013 Part One: Core Concepts, High Availability, Certificate and SharePoint considerations
- Workflow Manager Farms for SharePoint 2013 Part Two: End to End Configuration using Auto Generated Certificates and NLB
- Workflow Manager Farms for SharePoint 2013 Part Three: Switching an existing farm to use Domain CA issued certificates
- Workflow Manager Farms for SharePoint 2013 Part Four: End to End Configuration using Domain CA issued certificates
- Offline Installation of Workflow Manager in SharePoint Development Environment
- Web Platform Installer v5 Command Line (WebPICMD.exe) - RTW release
Здравствуйте! Скажите пожалуйста, Workflow Manager можно поставить на выделенный сервер вместе с Office Web Apps?
Наверно можно. Я не пробовал.
https://social.technet.microsoft.com/Forums/office/en-US/38d83841-7c1a-45b9-a786-403df8a2c47a/workflow-manager-on-office-web-app-server?forum=sharepointadmin
http://yalla.itgroove.net/2013/05/07/can-the-new-workflow-engine-be-installed-on-a-sharepoint-server/
Подскажите пожалуйста, в команде
"Register-SPWorkflowService –SPSite "???" Какой адрес указывать? Сервера, Веб приложения или семейства веб-сайтов? Я указал адрес веб-приложения, в котором несколько семейств веб сайтов. Правильно? Или лучше сразу имя сервера? Заранее спасибо!
https://technet.microsoft.com/ru-ru/library/jj663115.aspx
Спасибо за ссылку, я эту тему уже изучал. Только не могу понять одно. Если у меня несколько семейств веб-сайтов, и я укажу только одно, то будут ли работать процессы workflow на других семействах? Или для остальных семейств нужны повторные команды?
Например. Есть веб-приложение "work.lan" в нем несколько семеств \, \buh, \manager. Если я укажу семейство work.lan будет ли работать на work.lan\buh? Ведь с главного семейства не передаются права по наследству на другие семейства, вот и возникает вопрос по worflow.
Где-то я читал, что в параметр -SPSite можно указать ссылку на любое семейство сайтов.
Причем Workflow Service будет доступен на уровне всей фермы.
Грубо говоря командлет Register-SPWorkflowService цепляет Workflow Manager ко всей ферме, а не к конкретному семейству сайтов.
Спасибо за статью. Благодаря ей установилось все без проблем.
Но так и не запустился Workflow Service - Workflow is Not Connected
http://doc:12291 - отражает страницу
IIS WorkflowMgmtPool в состоянии Работает
Get-WFFarmStatus показывает 2 запущенных процесса: WorkflowServiceBackend и WorkflowServiceFrontEnd.
Сама регистрация прошла без ошибок
Register-SPWorkflowService –SPSite "http://doc" –WorkflowHostUri "http://doc:12291" –AllowOAuthHttp
Есть идеи, что еще не хватает.
Спасибо.
Обратная ссылка: Ошибка Workflow Manager "The provided signing certificate is invalid according to its expiration claims" в SharePoint 2013. Обновляем Self-Signed сертификат для служб Service Bus и Workflow Manager — Блог I /