Ошибка Workflow Manager «The provided signing certificate is invalid according to its expiration claims» в SharePoint 2013. Обновляем Self-Signed сертификат для служб Service Bus и Workflow Manager
В рассматриваемой ранее процедуре развёртывания Workflow Manager 1.0 для его последующей интеграции в SharePoint Server 2013 нами была использована схема с генерацией само-подписанного сертификата, который используется для веб-сервисов Workflow Manager (WFM) и Service Bus (SB). С тех пор прошло много времени, и наш экземпляр WFM всё это время выполнял свои задачи вполне себе штатно, пока не наступил момент, когда все новые рабочие процессы дружно перестали выполняться.
Забегая вперёд, можно сказать, что это ещё одна история о том, как отсутствие проактивного мониторинга срока действия важного цифрового сертификата может в перспективе создать трудности, которые потом придётся героически преодолевать.
Началось всё с того, что на веб-узле SharePoint Server, использующем вызовы выделенного сервера WFM, мы обнаружили информацию о возникающем исключении при вызове рабочих процессов » The provided signing certificate is invalid according to its expiration claims «
Все новые рабочие процессы были не в состоянии запуститься, выдавая нам эту однотипную ошибку.
После того, как мы заглянули в свойства веб-сайта WFM, стало очевидно, что истёк 5-летний срок действия само-подписанных сертификатов, которые были установлены на этапе развёртывания WFM. И мы этот момент благополучно проморгали.
Соответственно, для решения проблемы с падающими рабочими процессами WFM в SharePoint нам потребовалось выполнить обновление сертификатов, используемых для веб-сервисов Workflow Manager и Service Bus.
В целом процедура замены сертификатов не сильно сложная и её описание можно найти в (пока ещё доступной) статье Хосе Пендана Changing my Workflow Manager Farm Certificates. Однако, в нашем случае ситуацию усугубило то обстоятельство, что установленные сертификаты уже просрочены, поэтому описанная последовательность команд просто так не заработала. В частности, при попытке выполнения командлета установки нового сертификата для службы Service Bus (Set-SBCertificate) мы получили ошибку, говорящую о том, что старый установленный сертификат не найден (хотя на самом деле он есть в личном хранилище системы, но просрочен)
Помимо этой проблемы последующие эксперименты выявили то, что новый выпущенный в доменной службе сертификации «модный» сертификат c CNG key не подойдёт, так как требуется сертификат с Legacy key, чтобы в запросе KeySpec был определён как KeyExchange (AT_KEYEXCHANGE). В общем здесь можно было озадачиться созданием кастомизированного запроса к центру сертификации, а можно пойти иным путём – с помощью PowerShell сгенерировать новый само-подписанный сертификат, скопировав все нужные характеристики из старого сертификата. Далее мы рассмотрим процедуру создания такого сертификата и установки его в службы WFM/SB с учётом того обстоятельства, что текущий сертификат уже просрочен.
Итак, первым делом нам нужно сгенерировать новый сертификат в формате, приемлемом для WFM/SB. Но для этого нам потребуется знать отпечаток (Thumbprint) текущего установленного сертификата. Узнать отпечаток можно, запустив с правами администратора на сервере WFM консоль Workflow Manager PowerShell …
…и выполнив команду:
В нашем примере старый сертификат имеет отпечаток 628B16254CB5D0259567786051CE7F0F8814DB29 . От него в дальнейшем мы и будем отталкиваться.
Откат времени на сервере SB/WFM
Перед тем, как генерировать новый сертификат, сделаем так, чтобы на следующем шаге мы смогли установить этот новый сертификат без выше описанной ошибки. То есть нам потребуется вернуть систему в то время, когда действующий просроченный сертификат ещё не считался просроченным.
Например, в нашем случае сертификат истёк 02.04.2019, поэтому мы выставляем системное время на сервере WFM на 01.04.2019.
Чтобы время автоматически заново не устанавливалось на актуальное, пока мы не закончим процедуру замены сертификатов, остановим системные службы, отвечающие за синхронизацию времени. Это, как минимум, служба Windows Time (W32Time) и, в случае, если наш сервер WFM виртуальный, служба Hyper-V Time Synchronization Service (vmictimesync).
Генерация нового Self-Signed сертификата
Изменив время, откроем с правами администратора стандартную консоль Windows PowerShell и сгенерируем новый само-подписанный сертификат, скопировав при этом все параметры старого само-подписанного сертификата:
В результате выполнения последней команды на консоль будет выведен отпечаток сгенерированного само-подписанного сертификата. Запомним его, так как он понадобится нам дальше.
После генерации сертификат попал в хранилище личных сертификатов системы, но так как он является само-подписанным, нам потребуется добавить этот же сертификат и в хранилище корневых сертификатов доверенных ЦС — Trusted Root Certification Authorities. Сделать это можно либо через графическую консоль управления сертификатами, либо здесь же с помощью PowerShell:
В итоге наш новый само-подписанный сертификат должен стать доступен для выбора и в оснастке IIS. При открытии он должен отображаться, как валидный.
Напоминаю, что на сервере WFM всё ещё установлена дата из прошлого, поэтому старый само-подписанный сертификат, установленный в службах WFM/SB считается ещё действующим.
Установка сертификата в службы Service Bus
Возвращаемся в консоль Workflow Manager PowerShell и пробуем установить новый само-подписанный сертификат в службы Service Bus.
Как видим, на этот раз установка нового сертификата прошла успешно. Теперь нужно последовательно выполнить команды остановки фермы SB, обновления хоста и повторного запуска фермы.
Все команды должны отработать без ошибок и службы SB должны успешно запуститься.
Установка сертификата в службы Workflow Manager
Здесь же, в консоли Workflow Manager PowerShell выполняем последовательно команды установки нового само-подписанного сертификата в службы Workflow Manager и их перезапуск.
Как видим, указанный нами сертификат успешно установлен, однако в конфигурации WFM остаётся ссылка на ещё один просроченный сертификат — Outbound Certificate. Заменить этот сертификат на новый можно последовательностью команд следующего вида:
Результат можно проверить командой:
На этом манипуляции на сервере SB/WFM можно считать законченными.
Теперь дату в системе можно вернуть в актуальное состояние, а также нужно не забыть о запуске ранее остановленных служб синхронизации времени, таких как Windows Time (W32Time) и Hyper-V Time Synchronization Service (vmictimesync).
Настройка на стороне SharePoint Server
На стороне сервера SharePoint Server копируем выпущенный нами новый само-подписанный сертификат в хранилище Trusted Root Certification Authorities, чтобы система доверяла этому сертификату. Сделать это можно, как с помощью PowerShell (пример выше), так и с помощью графической консоли управления сертификатами, подключившись к хранилищу сертификатов Local Computer.
Далее открываем консоль SharePoint Management Shell и устанавливаем новый сертификат из локального хранилища Trusted Root Certification Authorities в специальное хранилище SharePoint.
Получить полный список хранилища доверенных корневых сертификатов в SharePoint можно командой:
После того, как сертификат установлен, командой iisreset перезагружаем IIS на всех серверах SharePoint Web Front End.
Далее, переходим на веб-узел администрирования SharePoint 2013 Central Administration и в разделе Monitoring \ Check job status находим задачу «Refresh Trusted Security Token Services Metadata feed» и запускаем его выполнение.
После этого переходим на веб-сайт SharePoint, где изначально наблюдалась проблема с запуском рабочих процессов, пытаемся возобновить подвисший рабочий процесс и убеждаемся в его успешном запуске
А чтобы в дальнейшем избежать ситуаций с остановкой WFM из-за просроченного сертификата, конечно-же следует озадачиться вопросом проактивного мониторинга срока действия установленных сертификатов. Но это, как говорится, уже совсем другая история.
Осваиваем Windows Server 2012, часть 2: Server Manager
В отличие от системы Windows 8 управление сервером не ограничивается рамками локальной системы. Речь идет об удаленном управлении несколькими серверами и их ролями. Здесь на первый план выходит оснастка Windows Server 2012 Server Manager
В опубликованной в предыдущем номере статье «Осваиваем Windows Server 2012, часть 1» я рассказывал о том, как использовать интерфейс нового экрана Start и связанные с ним сочетания клавиши Winkey для выполнения локальных серверных задач. Однако в отличие от системы Windows 8 управление сервером не ограничивается рамками локальной системы. Речь идет об удаленном управлении несколькими серверами и их ролями. Здесь на первый план выходит оснастка Windows Server 2012 Server Manager.
Оснастка Server Manager устанавливается вместе с любой версией системы Windows Server 2012 с полным графическим пользовательским интерфейсом и по умолчанию автоматически запускается при регистрации в системе. Однако не обязательно регистрироваться на сервере с системой 2012, чтобы использовать оснастку Server Manager. Вы можете установить пакет Remote Server Administration Toolkit (RSAT) for Windows 8 (в данный момент находится на стадии подготовки), чтобы запускать оснастку Server Manager на клиентской системе Windows 8 (и только этой версии).
Оснастка Server Manager состоит из трех основных секций (экран 1): панель областей управления, панель подробностей и файловое меню. Не знаю, является ли данный набор самым актуальным (похоже, он меняется с каждым релизом), но предполагаю, что эти названия вам знакомы. Панель областей управления содержит общий набор областей применения оснастки Server Manager. При выборе одного из элементов на панели областей управления содержимое панели подробностей изменится, и вы получите подробную информацию по выбранной области. Файловое меню в правом верхнем углу – наиболее простой способ получить доступ ко множеству задач управления серверами в выбранной области управления.
Экран 1. Обзор сервера |
Чтобы облегчить понимание отображаемой в консоли Server Manager информации, давайте отберем пять серверов в данном окружении, определив их операционные системы и установленные роли:
Консоль Server Manager использует менее подробное отображение информации, чем предыдущие версии управляющих консолей, и демонстрирует состояние системы с помощью «плиток» и цветов. В результате консоль полностью использует всю предоставляемую площадь монитора. При работе с более низким разрешением панель областей управления будет автоматически сжиматься, когда вы «проваливаетесь» в определенные серверные роли и группы. Первым делом вы, скорее всего, захотите скрыть область Quick Start, позволив, таким образом, всем ролям/группам разместиться на экране.
Добавление серверов и групп серверов
Как я говорил, файловое меню содержит множество задач, которые вы можете выполнить как на серверах, так и в самой консоли Server Manager. Вкладка Manage позволяет вам добавлять серверы в консоль Server Manager (при этом учтите, что вы не сможете удалить их из консоли), добавлять и удалять роли и компоненты на отслеживаемые серверы, регулировать некоторые базовые настройки Server Manager и создавать группы серверов. Давайте создадим группу серверов прежних версий, в которую будут входить только серверы с установленной операционной системой Windows Server 2008 R2. Выбор пункта меню Manage, Create Server Group вызывает окно выбора серверов, которые являются членами группы (экран 2). Обратите внимание на вкладки в верхней части области выбора – вы можете выполнять поиск по службе DNS, серверному пулу, импортированному списку или каталогу Active Directory. Я поддерживаю подробное описание, но данная структура настолько проста и прозрачна, что подробности проще будет опустить. При поиске серверов для группы Legacy Servers я использовал каталог AD, чтобы выбрать системы только с 2008 R2 или Windows 7. Еще один недостаток: список отбора операционных систем содержит одновременно и серверную, и клиентскую операционные системы определенного поколения (например, 2008 R2 и Windows 7), а не просто серверную операционную систему. Консоль Server Manager – это не больше и не меньше чем средство управления серверами, и она имеет ограниченные возможности в управлении клиентскими системами. К тому же в корпоративном окружении такой параметр быстрого отбора заставит вас прокручивать тысячи клиентских машин, чтобы найти необходимые серверы.
Экран 2. Создание группы серверов |
Мониторинг серверов старых версий
Единственными старыми операционными системами, состояние которых может отслеживать консоль Server Manager, являются системы Windows Server 2008 или 2008 R2. Чтобы обеспечить возможность мониторинга этих серверов в консоли Windows Server 2012 Server Manager, вы должны сделать следующее.
* Установить пакет. NET Framework 4.0. Я подозреваю, что на большинстве серверов, для которых проводится регулярное обновление, он уже установлен.
* Установите пакет Windows Management Foundation 3.0. Этот пакет содержит обновления для инструментов PowerShell 3.0, WMI и WinRM.
* Возможно, вам придется установить обновления, описанные в статье KB 2682011 (http://go.microsoft.com/fwlink/p/?LinkId=245487). И опять же, если вы своевременно обновляете системы, то я подозреваю, что этот пакет уже установлен. Подробную информацию об удаленном мониторинге серверов с помощью Windows Server 2012 Server Manager можно найти в статье «Configure Remote Management in Server Manager» (http://technet.microsoft.com/en-us/library/hh921475).
Как только серверы с системой 2008 R2 были выделены в отдельную группу и «плитку», сразу стало очевидно, что возникли проблемы с взаимодействием консоли Server Manager и серверов R2 (экран 3). При этом оставались проблемы с мониторингом этих старых операционных систем. Щелчок мыши на элементе Manageability с тремя ошибками в «плитке» Legacy Servers выявил проблемы с получением данных со всех трех систем R2 (экран 4). Чтобы скрыть эти ошибки или другие ошибки, какие вы сочтете нужным, раскройте список выбора Status и снимите выделение с соответствующей записи. Строка вернется в нормальное состояние.
Экран 3. «Плитки» |
Экран 4. Ошибки получения данных из систем R2 |
Инструменты и уведомления
В файловом меню есть еще два важных пункта: Tools и Notifications. Tools – это замена консоли Administrative Tools в системе Windows Server 2012. Именно сюда необходимо зайти, если вы хотите напрямую вызвать знакомые инструменты (например, Active Directory Administrative Center, Group Policy Management, DNS и так далее), а не использовать рабочую панель Roles.
Notifications – это флажок, меняющий цвет на красный, если какие-либо элементы требуют вашего внимания (экран 5). Хотя данная функциональность отчасти повторяет уведомления рабочей области, преимущество флага Notifications состоит в том, что он остается всегда видимым, даже если вы углубляетесь в определенные области консоли Server Manager и не видите рабочую область.
Экран 5. Notifications |
Давайте вернемся в панель областей управления и рассмотрим оставшиеся способы просмотра информации по вашим серверам. Области Local Server и All Servers позволяют управлять множеством серверов, используя вертикальный (в моем понимании) подход, то есть предоставляя управление всеми установленными ролями, компонентами и службами на сервере.
Область роли
Помимо областей Dashboard, Local Server, All Servers и любых созданных групп серверов (например, Legacy Servers), панель областей автоматически дополняется значками, соответствующими всем серверным ролям, находящимся под вашим управлением (экран 6). Такой подход позволяет взглянуть на ваши серверы «в разрезе»: распространение определенной роли по множеству серверов.
Экран 6. Обзор роли |
Давайте взглянем на роль AD DS (экран 7). Каждая область представляет собой набор окон (в данном случае окон Servers, Events, Services, Best Practices Analyzer (BPA), Performance и Roles and Features). Вы можете щелкнуть правой кнопкой мыши на каждой записи в окне и получить доступ к задачам контекстного меню. В каждой области также имеется «вон та штука» под названием Tasks в правом верхнем углу каждого окна, которая представляет собой дополнительную точку запуска задач. Такое многообразие способов запуска задачи в консоли Server Manager, позволяет просто выбрать один из способов выполнения задачи. Например, запомните, что пункта Remove Server нет в файловом меню Manage, содержащем пункт Add Server. Вы можете удалить сервер из окна мониторинга, щелкнув по нему правой кнопкой мыши, либо из области Servers или любой области роли, в которой представлен данный сервер.
Экран 7. Роль AD DS |
Новый мощный интерфейс управления
Вы можете многое узнать о возможностях Server Manager, щелкнув правой кнопкой мыши в любой области и просмотрев разрешенные операции в контекстном меню. Например, можно перезагрузить один (или все, в зависимости от выбранного количества) сервер из области All Servers, щелкнув правой кнопкой и выбрав операцию Restart Server. Вы можете настроить объединение сетевых интерфейсов, запустить удаленную сессию PowerShell или воспользоваться другими известными механизмами администрирования. Такой подход приводит к интересным эффектам при использовании старых, не обновленных до последней версии инструментов. Например, приложение LDP.EXE, запускается три раза (каждый раз для определенного контроллера домена), когда я выбираю данную команду для выборки из трех контроллеров домена. Соблазнительная возможность, ведь большинство популярных инструментов командной строки представлены в контекстном меню – однако они просто запускаются и «вылетают» по ошибке, так как вы не указали (и не могли указать) необходимые параметры.
Чего мне не хватало, так это возможности использовать кнопку мыши «назад» для возврата к предыдущему экрану, например, если вы углубились в изучение определенной роли и захотели вернуться к общему виду. Я удивлен, что эта кнопка не работает, так как мы говорим о базовой функции, которой мне стало не хватать спустя три минуты с момента начала использования Server Manager.
После того как вы привыкнете к интерфейсу консоли Server Manager, он покажет себя во всей красе. Например, область роли помогла мне обнаружить, что я установил роль AD DS на виртуальную машину SCVMM, но не повысил сервер до контроллера домена. Средство BPA предложило мне применить политику Default Domain Controllers Policy на подразделение Servers. И что же? При дальнейшем исследовании я обнаружил не до конца настроенную роль AD DS на сервере SCVMM, который входит в подразделение Server OU. Лучше бы средство BPA сообщило мне, что у меня есть сервер, на котором установлена роль AD DS, но он не входит в подразделение Domain Controllers.
Server Manager или экран Start?
Одной из главных проблем при работе как с консолью Server Manager, так и с экраном Start в системе Windows Server 2012 является поиск расположения привычных задач и витиеватых маршрутов, по которым к ним можно добраться. В общем, мне действительно понравилась консоль Windows Server 2012 Server Manager. Она имеет удобный интерфейс, который позволяет управлять удаленными и локальными серверами, а также просматривать их состояние с разных сторон, например, увидеть установленные роли, уровень операционной системы или использовать любую другую группировку. Механизмы интерфейса немедленно уведомляют вас о появлении предупреждений или ошибок, а вы можете выполнять различные действия для нескольких серверов, что раньше было невозможно.
Но я до сих пор сомневаюсь в целесообразности использования нового экрана Start и связанных с ним сочетаний клавиши Windows Key для управления серверами – особенно для удаленного управления «через консоль» посредством сессий Remote Desktop. А если вы не установите параметр Apply Windows key combinations on the remote computer в настройках Local Resources подключения Remote Desktop Connection, парадигма использования нового экрана Start становится практически непригодной. Не все управляют крупными «облачными» центрами обработки данных, поэтому я верю, что настанет время, когда операторы сервера будут использовать сенсорные экраны на серверных консолях для просмотра красных «плиток» консоли Server Manager в поисках ошибки. Но в тоже время, я думаю, пройдет немало времени, прежде чем специалисты будут администрировать свои серверы через сенсорные экраны. Механизмы экрана Start в серверных системах выглядят уверткой, связанной со спущенным «сверху» решением о том, что все версии Windows должны иметь одинаковый интерфейс, независимо от соответствия этого интерфейса требованиям платформы, или, что еще хуже, последствий этого решения.
Поделитесь материалом с коллегами и друзьями