Не запускается Server Manager


Уже втрой раз за несколько месяцев после установки ежемесячных обновлений Service Manager не может запуститься и подает в дамп.

Ситуация описана в https://social.technet.microsoft.com/Forums/en-US/d7e48460-bc23-4288-b976-98e7952d1517/server-manager-crashes-on-opening-on-windows-server-2016?forum=winservermanager

Код ошибки 1026. Смое важное в сообщении об ошибке:

Microsoft.Windows.ServerManager.Common.Data.RoleFeatureRoot..ctor(System.Collections.Generic.ICollection`1<Microsoft.Windows.ServerManager.Common.Data.IFeature>)
   at Microsoft.Windows.ServerManager.Common.Data.Server.UpdateFeatures(System.Collections.Generic.ICollection`1<Microsoft.Windows.ServerManager.Common.Data.IFeature>,

Статья на форуме Technet полезная, но не раскрывает всех секретов.

«UpdateFeatures» в сообщении об ошибке навивает на мысли. Фактически Server Manager не может получить список установленных компонентов.

Основная хитрость в том, что Server Manager использует PowerShell Remoting для подключения к серверам. Иначе говоря, если вы будете делать проверки локально, то не увидите проблему. Нужно проверять именно удаленное подключение.

Service Manager фактически использует для получения списка установленных компонент командлет Get-WindowsFeatures. Чтобы выполнить проверку правильно даже на локальном сервере, необходимо использовать параметер ComputerName:

Get-WindowsFeatures -ComputerName "server"

Если этот командлет вернет ошибку «Данный ключ отсутствует в словаре.» / «The given key was not present in the dictionary.», значит вы нашли поврежденный сервер.

Для лечения выполняем на нём команду:

dism /online /enable-feature /featurename:IIS-ASPNET45 /all

Остаётся только один вопрос: что если в Service Manager добавлено много серверов? Перебирать их вручную не очень интересное занятие. К тому же поврежденными могут оказаться серверы не подключенные в данный момент к Service Manager, но проблема может всплыть позднее в самое неподходящее время. Следовательно надо проверить все серверы и вылечить их.

# Получить список имен серверов, которые пингуются.
# Это значительно ускоряет процесс.
$servers = Get-ADComputer -SearchBase "OU=Servers,DC=firm,DC=ru" -Filter * | Select-Object -ExpandProperty Name | Where-Object { Test-Connection -ComputerName $_ -Count 1 -ErrorAction SilentlyContinue }

# Проверяем каждый сервер на конкретную этой ситуации ошибку.
$brokenServers = $servers | Where-Object { (Get-WindowsFeature -ComputerName $_ -ErrorVariable err -ErrorAction SilentlyContinue) -and ($err.Exception -is "System.Collections.Generic.KeyNotFoundException") }

$brokenServers

# Если найден поврежденный сервер, то выполняем на нем команду:
dism /online /enable-feature /featurename:IIS-ASPNET45 /all

PowerShell 7.1 Preview7


Вышла последняя предварительная версия PowerShell 7.1 Preview7. Вскоре будет RC и сам релиз. Так что пробуйте, тестируйте и поторопитесь сообщить о проблемах, если они обнаружатся.

Что нового?

  1. Команда MSFT начала проект по реструктуризации SMA.dll на подсистемы. Это позволит создавать дистрибутивы с минимальным набором функций.
  2. Тип Utf7 более не поддерживается. Вы получите предупреждение, если скрипт использует этот тип. Причина простая — в .Net 5.0 этот тип объявлен как deprecated. В будущем он будет удален вообще. Собственно ничего страшного, так как Uft7 никогда не используется.
  3. В Web командлетах теперь можно указать использование Tls13. Так как командлеты используют возможности операционной системы, а поддержка TLS 1.3 во всех ОС сейчас ограниченная, то не стоит ожидать, что это будет работать прямой сейчас.

Стоит отметить, что Preview7 основано на .Net 5.0 Preview8, где удалена встроенная поддержка WinRT. Теперь существует отдельный проект поддержки WinRT API в C#. Это уже породило проблемы с некоторыми модулями. Кое-что уже исправлено в PowerShell, кое-что в .Net. Надеюсь, к моменту выхода .Net 5.0 обратная совместимость будет на высоте.

Странности в развитии PowerShell Remoting


Речь о PowerShell 6/7 в первую очередь. Традиционно для удаленного доступа Windows PowerShell использовал технологию WS-Management, или WSMan. Когда вышел PowerShell 6 там появилась возможность использовать SSH в качестве альтернативы, но при этом была добавлена ограниченная поддержка WSMan на Linux и MacOS. Внезапно эта поддержка прекратилась. При этом никаких ясных заявлений от MSFT не было. По всей видимости произошли внутренние разногласия между различными подразделениями огромной компании по поводу приоритетов и направлений развития. Скорее всего они сами надеялись как-то разрулить ситуацию со временем, но за несколько лет ситуация только ухудшилась, превратилась в абсурдную, когда новое ещё до конца не создано (переход экосистемы на SSH), а старое уже не только не развивается, но и не работает (WSMan на Unix).

Да, WSMan на Unix толком не работает. Причина в том, что реализация жестко привязана к SSL 1.0.0, которая в большинстве систем не устанавливается как устаревшая и небезопасная.

Цепочка зависимостей выглядит так WSMan -> PSRPClient -> libmi — OMI. Проблема в стыке libmi и OMI. В OMI есть проблемы с SSL. Команда MSFT OMI отказывается вносить изменения, так как это deprecated проект и это не соответствует их приоритетам. В свою очередь команда MSFT PowerShell не может исправить libmi. Эта библиотека также объявлена deprecated.

В репозитории PowerShell существует множество вопросов по этому поводу. Только в последнее время команда MSFT PowerShell стала говорить о том, что WSMan не поддерживается на Unix, и все должны использовать SSH транспорт.

При этом существуют обходные пути, как установить более новую версию SSH и создать линки так, чтобы WSMan заработал на Unix. Он еще долго будет нужен, т.к. существует огромная экосистема, где он используется. Включая Облачные сервисы. Даже новый модуль Exchange Online V2 использует WSMan. Пользователи PowerShell на Unix могли бы остаться в стороне, если бы не альтернативный проект поддержки.

Если у вас есть потребность в WSMan на Unix посмотрите эту статью и поддержите проект.

А что MSFT? Протокол SOAP объявлен deprecated. Почему я упомянул его? WSMan на Windows реализован поверх SOAP (MMI.dll).

Таким образом не только Unix, но и Windows системы идут по пути миграции PowerShell Remoting на SSH.

Команда MSFT PowerShell только что начала предпринимать реальные шаги по изживанию Management Instrumentation (libmi.dll/mmi.dll). Сейчас она ведет соответствующие работы над DSC. Конечно это будет постепенный процесс. Посмотрите — это интересно. Хотя похоже на проклятье — жить в эпоху перемен :-)