Установка и настройка Workflow Manager 1.0 CU2 на Windows Server 2012 R2 для интеграции с SharePoint Server 2013 SP1

imageВ рамках внедрения одного локального проекта разработанного под 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)

image

 

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.

image

При создании алиаса помним про требование в документе Требования к системе (Workflow Manager 1.0) исходя из которого длина имени не сервера БД должна превышать 15 символов, хотя по сути такое требование справедливо только при использовании Именованных каналов (Named pipes) для подключения к SQL Server.

Теперь нужно проверить созданные нами SQL-алиасы. Для этого создадим пустой файл Universal Data Link с расширением *.udl и запустим его. На закладке Connection укажем SQL-алиас, выберем режим аутентификации Use Windows NT Integrated security и нажмём кнопку Test Connection

image

Если мы всё сделали правильно, то получим положительный результат подключения. При этом перечень всех активных БД на новом 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) и выполнить его установку (опять же из командной строки с правами администратора)

image

Теперь с помощью установленного 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

В результате мы должны получить внушительный список продуктов доступных к установке

image

Внимательно изучаем этот список на предмет необходимых нам компонент, чтобы узнать их идентификаторы. 

Следующей командой будет выполнена загрузка компонент с соответствующими идентификаторами  WorkflowManagerRefresh, WorkflowClient, ServiceBus_1_1 в заранее созданный сетевой каталог на файловом сервере, созданный для удобства общего использования специально под хранение кэша Web Platform Installer:

WebPiCmd /Offline /Products:"WorkflowManagerRefresh,WorkflowClient,ServiceBus_1_1" /Path:\\holding.com\Software\WEB-PI-OFFLINE-CACHE

image

image

В нашем примере по завершению процедуры загрузки общий размер каталога автономного кэша инсталляторов составил 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

image

image

В процессе установки будет включена серверная роль Web Server (установлены компоненты IIS) и установлено несколько приложений необходимых для работы Workflow Manager…

image

 

6. Создаём ферму Workflow Manager

Сразу после завершения процедуры установки будет запущен мастер настройки Workflow Manager Configuration Wizard. Процесс установки в разных вариантах полностью описан в документе Creating a New Farm.

В нашем примере выбран вариант расширенной настройки Configure Workflow Manager with Custom Settings

image

В форме настроек 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 оставим предложенные по умолчанию.

image

 

В качестве Service Account укажем созданную ранее доменную учетную запись s-KOM-AD01-WF-Mgr

image

 

Включим авто-генерацию сертификатов SSL, необходимых для защиты межкомпонентных соединений WM.

Ключ Certificate Generation Key нужно записать в отдельное место, так как он потребуется нам в случае, если мы решим расширить ферму Workflow Manager дополнительным сервером.

image

 

Значения используемых 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

image

Кнопкой стрелки переходим ко второму этапу настройки – Service Bus Configuration.

Имя сервера SQL и баз данных Farm Management Database, Gateway Database и Message Container Database оставляем предложенные по умолчанию, проверяя возможность их последующего создания с помощью кнопок Test Connection

image

 

В качестве Service Account будем использовать туже учетную запись, что использовали для WM включив опцию Use the same service account credentials as provided for Workflow Managerimage

Так же как и для WM включим авто-генерацию сертификатов (Auto-generate) и используем тот же Certificate Generation KeyUse the same certificate generation key as provided for Workflow Manager.

image

Порты оставляем в значениях по умолчанию. Для них с включённой опцией Enable firewall rules on this computer также автоматически будут созданы разрешающие правила в брандмауэре Windows.

В параметре Configure Admin Group укажем имя созданной нами ранее группы безопасности KOM\KOM-AD01-Workflow-Manager-DB-Admins

image

На экране Summary ещё раз проверяем все заданные настройки и нажимаем кнопку конфигурирования в нижнем правом углу…

image

Дожидаемся окончания процесса конфигурирования…

image

После успешного окончания установки убеждаемся в том, что в Windows Firewall созданы разрешающие правила для входящих подключений как было определено в Workflow Manager Configuration Wizard.

На SQL сервере проверяем созданные БД и при необходимости меняем для них Recovery model с установленного по умолчанию Full на Simple.

image

 

Проверяем доступность Workflow Manager с сервера SharePoint открыв на нём в Internet Explorer (запускать с правами Администратора и с отключенными настройками прокси) ссылку
http://WFM-Server.holding.com:12291

image

 

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 

image

 

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 ApplicationsManage service applications в списке служб должна появится Workflow Service Application Proxy. При её открытии мы должны увидеть статус Connected

image

***

На этом процесс установки и настройки 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 v4 Command Line (WebPICMD.exe) — RTW release
Brian the PFE   >  Least Privilege Configuration for Workflow Manager with SharePoint 2013

Всего комментариев: 8 Комментировать

  1. Pavel /

    Здравствуйте! Скажите пожалуйста, Workflow Manager можно поставить на выделенный сервер вместе с Office Web Apps?

  2. Pavel /

    Подскажите пожалуйста, в команде
    «Register-SPWorkflowService –SPSite «???» Какой адрес указывать? Сервера, Веб приложения или семейства веб-сайтов? Я указал адрес веб-приложения, в котором несколько семейств веб сайтов. Правильно? Или лучше сразу имя сервера? Заранее спасибо!

    1. Pavel /

      Спасибо за ссылку, я эту тему уже изучал. Только не могу понять одно. Если у меня несколько семейств веб-сайтов, и я укажу только одно, то будут ли работать процессы workflow на других семействах? Или для остальных семейств нужны повторные команды?

      1. Pavel /

        Например. Есть веб-приложение «work.lan» в нем несколько семеств \, \buh, \manager. Если я укажу семейство work.lan будет ли работать на work.lan\buh? Ведь с главного семейства не передаются права по наследству на другие семейства, вот и возникает вопрос по worflow.

  3. Владимир /

    Где-то я читал, что в параметр -SPSite можно указать ссылку на любое семейство сайтов.
    Причем Workflow Service будет доступен на уровне всей фермы.

    Грубо говоря командлет Register-SPWorkflowService цепляет Workflow Manager ко всей ферме, а не к конкретному семейству сайтов.

  4. Евгений /

    Спасибо за статью. Благодаря ей установилось все без проблем.
    Но так и не запустился 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

    Есть идеи, что еще не хватает.
    Спасибо.

Добавить комментарий