Окопная история: Эй, Microsoft, не говорите нам RTFM, если у него есть ошибки в документации!

Некоторое время назад один коллега сообщил мне о разочаровании другого коллеги, пытавшегося завершить миграцию инфраструктуры управления правами на доступ к данным (IRM) организации с Windows RMS на AD RMS в Windows Server 2012 R2. Для тех из вас, кто не слишком знаком с этими технологиями, скажем, что Windows RMS была функцией уже устаревшей операционной системы Windows Server 2003, а AD RMS, что означает службы управления правами Active Directory, является ролью сервера в Windows Server 2012. которые организации могут использовать для расширения своей стратегии безопасности, защищая документы с помощью инструментов и технологий управления правами на доступ к данным. По мере того, как история разворачивается ниже, вы увидите, что миграции такого масштаба могут быть очень и очень привередливыми, чтобы выполнять множество сложных шагов и вещей, о которых нужно беспокоиться. И вы также увидите такие безобидные мелочи, которые портят все и загоняют в стену даже опытных ИТ-специалистов. Еще раз, я запутал некоторые детали этой истории, которые могли бы идентифицировать причастных к ней людей и организации, а также немного изменил историю, чтобы сделать ее более интересной и создать некоторую напряженность. Но, как вы скоро увидите, мораль этой истории на самом деле не имеет ничего общего с RMS и на самом деле имеет гораздо более широкое применение.

Проблема

Консультант (назовем его Боб) начал с того, что решил следовать официальной пошаговой документации Microsoft по переходу с Windows RMS на AD RMS, которую можно найти здесь, на TechNet. В конце концов, насколько это может быть сложно, если поставщик предоставил вам подробную дорожную карту, которой нужно следовать?

В любом случае Боб тщательно выполнил все необходимые шаги, такие как обновление записей DNS, чтобы клиент мог найти новый сервер AD RMS, импорт доверенного домена публикации со старого сервера RMS в новую инфраструктуру и т. д. Выполнив все указанные в руководстве действия, он попытался открыть документ Microsoft Word, ранее защищенный с помощью Windows RMS, и обнаружил, что не может его открыть. Вместо этого Microsoft Word отобразил сообщение об ошибке, в котором говорилось: «В настоящее время невозможно проверить информацию о пользователе. Вы хотите открыть документ, используя другой набор учетных данных?» Это те вещи, из которых состоят ночные кошмары ИТ-специалистов, например, представьте, что все документы вашей организации станут нечитаемыми после завершения миграции.

Попытки найти решение

Боб обсудил свою проблему с несколькими коллегами, имевшими опыт и знания в области AD RMS, и они посоветовали проверить, сделал ли он все необходимое и перепробовал все возможное. Например:

• Убедитесь, что имя старого сервера является альтернативным именем субъекта в сертификате SSL для нового сервера RMS. (Проверять.)
• Убедитесь, что список отозванных сертификатов (CRL) находится в сети и доступен. (Проверять.)
• Попробуйте временно отключить проверку списка отзыва сертификатов в Internet Explorer на клиенте, чтобы проверить, сохраняется ли ошибка. (Готово. Ошибка все еще происходит.)
• Убедитесь, что новые URL-адреса службы управления правами добавлены в зону локальной интрасети в Internet Explorer на клиенте. (Проверять.)
• Убедитесь, что все URL-адреса, которые вы добавили в зону локальной интрасети, имеют правильный префикс, т. е. HTTP или HTTPS. (Да, они правы.)
• Выполнение трассировки сетевых пакетов, чтобы убедиться, что клиент действительно пытается связаться с новым сервером RMS. (Да, клиент пытается получить лицензию RMS с нового сервера.)
• Попробуйте очистить хранилище лицензий для версии Microsoft Office, установленной на клиенте. (Готово. Без изменений.)
• Просмотрите журналы IIS, чтобы узнать, записана ли там учетная запись пользователя, используемая на клиенте. Если нет, то проблема на стороне клиента, а не на сервере. (Учетная запись пользователя присутствует в логах).

И так далее.

Согреваюсь

Когда Боб пытался глубже изучить конфигурацию своего старого и нового серверов RMS, он заметил, что старый сервер RMS требовал HTTP вместо HTTPS для входящих подключений из Microsoft Word, пытающихся открыть документы на старом сервере. Некоторое исследование в Интернете привело его к этой статье Wiki на Microsoft TechNet, которая, похоже, конкретно касалась той ситуации, с которой он имел дело. В статье рекомендуется создать новое значение реестра с именем LicenseServerRedirection на клиенте, поэтому Боб добросовестно попробовал это сделать. К сожалению, это не сработало.

Затем коллега предложил открыть некоторые документы старого сервера с помощью Блокнота, чтобы увидеть, какой URL-адрес используется для сервера. Тем временем Боб провел еще одну сетевую трассировку и смог подтвердить, что Microsoft Word действительно пытался установить HTTP-соединение с новым сервером AD RMS вместо использования требуемого типа соединения HTTPS. Он попытался создать перенаправление в IIS с HTTP на HTTPS, но это не дало никакого эффекта.

Проведя дополнительные исследования, Боб открыл эту страницу в TechNet, где объясняются различные параметры реестра Microsoft Office и их назначение. На этой странице он нашел то же значение реестра с именем LicenseServerRedirection, что и раньше, но на этот раз значение, которое нужно было указать для настроек, отличалось от того, что было указано на странице Wiki. Боб попробовал этот другой синтаксис и, о чудо, теперь он мог открывать документы, зашифрованные на старом сервере RMS, с помощью нового сервера AD RMS!

Чему научился Боб из всего этого? Иногда документация может быть неправильной!

Насколько распространены ошибки в документации?

Отсутствуют какие-либо статистические данные о том, как часто возникают ошибки документации в продуктах Microsoft и других поставщиков программного обеспечения. Но за более чем 20 лет работы с продуктами Microsoft я сам сталкивался с несколькими ошибками в документации на страницах TechNet для Windows Server, Microsoft Exchange и совсем недавно для Windows PowerShell. Ошибки документации в выходных данных командлета PowerShell Get-Help кажутся наиболее распространенной формой ошибки документации в наши дни, и это может быть связано с ускорением темпов разработки PowerShell для серверной платформы и продуктов Microsoft. Разработчики, как правило, не самые лучшие, когда дело доходит до написания документации, не потому, что они не знают своего дела (они знают его наизнанку), а, вероятно, просто потому, что они так заняты разработкой и поэтому не слишком заботятся о том, чтобы получить пошаговые процедуры правильно, что позволяет закрадываться ошибкам документации.

Однако большая проблема заключается в том, что одна ошибка в документации может свести на нет часы или даже дни усилий, потраченных на устранение проблемы, с которой вы столкнулись. Если вы просто выполняете пошаговую процедуру на TechNet или другом сайте Microsoft и не можете заставить что-то работать, возможно, вам стоит заподозрить какую-то ошибку в документации. Это может быть неправильное значение реестра, отсутствующий шаг настройки, опечатка с надписью «Разрешить» вместо «Запретить» или какая-либо другая ошибка или упущение. Что делать, если вы подозреваете это?

Если вы открыли запрос в службу поддержки Microsoft, вам следует работать над этим до тех пор, пока ваша проблема не будет решена. Если выяснится, что проблема заключалась в ошибках в документации с их стороны, вам следует сильно надавить на службу поддержки Microsoft, чтобы отменить сбор за билет — поговорите с менеджером инженера службы поддержки или, если необходимо, с менеджером менеджера, чтобы убедиться в этом.

Если вы не открыли запрос в службу поддержки, поскольку являетесь потребителем или представителем малого бизнеса, не использующим программное обеспечение с корпоративной лицензией, попробуйте открыть сеанс чата со службой поддержки Майкрософт с этой страницы или ее эквивалента в вашей стране. Сразу же сообщите сотруднику службы поддержки, что вы подозреваете ошибки в документации, потому что вы следовали шагам точно так, как описано в их технической документации. Если это ни к чему не приведет, найдите подходящий форум TechNet, посвященный вашей проблеме, и разместите там подробное описание вашей проблемы. Первые несколько ответов, которые вы, вероятно, получите, будут, вероятно, готовыми ответами от инженеров службы поддержки Microsoft, но если вы продолжите шуметь, вы, вероятно, в конечном итоге заинтересуете нескольких коллег, которые могут иметь больше практического опыта работы с продуктом. (s), чем собственные люди поддержки Microsoft.

Имейте это в виду — скрипучее колесо получает смазку!

Один вывод: подумайте, прежде чем приступать к миграции

Позвольте мне закончить некоторыми размышлениями, касающимися технологий, о которых я говорил в начале этой статьи. Технологии безопасности для IRM постоянно развиваются, и с новой настойчивостью Microsoft в отношении облачных решений неудивительно, что Microsoft надеется заставить организации, использующие AD RMS, перейти на новую функцию Azure Information Protection в Microsoft Azure. Преимущества облачной Azure Information Protection по сравнению с традиционными локальными решениями AD RMS очевидны: не требуется серверная инфраструктура; встроенная поддержка мобильных устройств; облачная аутентификация; плюс еще куча настроек и вкусностей. Но миграция чего-то большого, подобного этому, по-прежнему является далеко не тривиальной задачей, и история в этой статье может служить своего рода предупреждением о том, что такая простая вещь, как ошибки в документации, может привести к многочасовым разочаровывающим усилиям по завершению миграции и получению нужного результата. новая система запущена и работает. Возможно, облачные решения, такие как Azure Information Protection, лучше оставить для организаций, которые еще не окунулись в пруд IRM. В конце концов, если ваше локальное решение работает, зачем его заменять? И помните — миграции, как правило, не очень весело.