Side-By-Side и другие особенности установки PowerShell Core


С выпуском PowerShell Core 6.1.0 сложилась следующая модель установки.

Пакеты

Поддерживаются следующие пакеты:
1. MSI (Windows)
2. deb (Debian, Ubuntu)
3. rpm (Redhat)
4. pkg (MacOs)

Также есть архивные файлы Zip (tar.gz).

Установка Side-By-Side

Side-By-Side означает, что вы можете установить на одной системе несколько версий PowerShell Core.

Обычно основная версия ставится из пакета в стандартную директорию (для Windows это C:\Program Files\PowerShell\6), а остальные вы можете распаковать из zip архива в любое место.

На Windows это также обеспечивает сосуществование с Windows PowerShell.

Почему пакет устанавливает PowerShell Core в одну и ту же стандартную директорию? Это сделано специально, чтобы обеспечить обновление версий с помощью менеджеров пакетов. На Windows это также обеспечивает получение обновлений через Windows Update и WSUS (это работает для GA версий, но не для Preview/RC). По этой же причине предустановленные модули ставятся в директорию без номера версии в названии. Обновляться они будут пакетом новой версии или через Windows Update/ WSUS.

Для пакетов надо помнить, что есть две независимые ветки — GA и Preview/RC. Имена пакетов соответственно powershell и powershell-preview (для RC также powershell-preview).
Для каждой ветки пакеты устанавливаются и обновляются независимо друг от друга. Это означает, что msi пакет (это верно и других видов пакетов) для версии 6.1.0 заменит версию 6.0.x, 6.1.1 заменит 6.1.0 и т.д., но оставит без изменения любую установленную Preview/RC версию. Аналогично пакет msi для версии 6.2.x-preview1 заменит любую младшую предварительную версию, а например 6.2.0-rc1 заменит 6.2.0-preview1.

Менеджеры пакетов.

Вы можете использовать стандартные apt-get, yum, zypper, dnf. Особенность в том, что пакеты лежат только в репозитории Microsft (https://packages.microsoft.com), и его нужно предварительно зарегистрировать на системе. В документации описано, как это сделать.
В дальнейшем планируется размещение пакетов в стандартных репозиториях и, возможно, в Windows Store.

Есть также Windows Docker Files and Images https://hub.docker.com/r/microsoft/windowsservercore/ и https://hub.docker.com/r/microsoft/nanoserver/

Недавно появился Snapcraft https://snapcraft.io/powershell и https://snapcraft.io/powershell-preview

Полезные ссылки:

1. https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell?view=powershell-6
2. https://github.com/PowerShell/PowerShell/blob/master/README.md
3. https://github.com/PowerShell/PowerShell/releases/
4. https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell-core-on-linux?view=powershell-6#snap-package

Реклама

PowerShell Core 6.1 выпущен!


Официальный анонс https://blogs.msdn.microsoft.com/powershell/2018/09/13/announcing-powershell-core-6-1/

Release Notes и загрузка https://github.com/PowerShell/PowerShell/releases

Также доступен в Snap. Постепенно расширяется число репозиториев, через которые можно установить PowerShell Core.

PowerShell Core 6.1 работает на базе .Net Core 2.1.

Самое приятное, что были найдены и исправлены некоторые проблемы производительности. Целый ряд командлетов теперь потребляет меньше памяти и работает существенно быстрее, даже лучше, чем Windows PowerShell.

Разработчики Microsoft проделали огромную работу по обеспечению совместимости с PowerShell модулями поставляемым с Windows 10 и Window Server 2019. Да, это доступно только для новых версий. Для старых надо использовать механизм проксирования реализованный в модуле WindowsConpatibility.

Больше подробностей об изменениях в статье https://isazonov.wordpress.com/2018/08/28/powershell-core-6-1-0-rc1/

PowerShell Core 6.1 Preview4


Вышла новая предварительная версия PowerShell 6.1 Preview4.

https://github.com/PowerShell/PowerShell/releases

RTM версия ожидается через несколько недель в августе.

На что стоит обратить внимание?

1. Add support to experimental features
https://github.com/PowerShell/PowerShell/pull/7242

Этот механизм позволит реализовывать альтернативные возможности в предварительных версиях. Пользователи смогут выключать и выключать их на свое усмотрение для тестирования.

2. Add ThreadJob module package and tests
https://github.com/PowerShell/PowerShell/pull/7169

Это ещё одна возможность распараллеливания выполнения скриптов. Рекомендую потестировать и написать отзывы, чтобы в августе получить обновленный вариант в RTM версии.

3. Enable UseShellExecute on all platforms
https://github.com/PowerShell/PowerShell/pull/7198

Теперь на Unix системах Invoke-Item будет работать как на Windows системах и запускать приложения в зависимости от расширения файла. Так Invoke-Item file.txt запустит текстовый редактор.

Остальное смотрите в Release Notes — ссылка выше.

Remote Desktop — медленное подключение


В Windows Server 2012 и Windows Server 2012 R2 есть небольшая, но неприятная, проблема, когда при подключении по RDP вы видите черный экран некоторое время, а в логе появляется событие Event ID 20499 «Remote Desktop Services has taken too long to load the user configuration from server …».

Лечение описано в статье https://support.microsoft.com/en-us/help/4021856/sbsl-issue-when-you-create-an-rdp-connection-to-windows-server . Собственно нужно добавить в реестр ключ fQueryUserConfigFromLocalMachine со значением 1.

В Windows Server 2016/2019 проблема уже исправлена, и ключ в реестр добавлять не нужно.

 

Модуль ActiveDirectory работает в PowerShell Core


Хорошая новость — в последних сборках Windows 10 Preview компонент RSAT содержит модуль ActiveDirectory совместимый с PowerShell Core!

Болеетого в PowerShell Core добавлена опция CompatiblePSEdition, которая позволяет распознавать модули совместимые с  PowerShell Core. Сейчас это будет использоваться для модулей входящих в состав Windows (ставятся в C:\Windows\System32\WindowsPowerShell\v1.0\Modules). MSFT сейчас активно работает над портированием этих модулей.

Exchange Server 2013 Extended Support


На днях вышло последнее кумулятивное обновление для Exchange Server 2013 — CU21. Exchange Server 2013 переходит в фазу расширенной поддержки с 19 сентября 2018 (хотя фактически уже сейчас). Это означает, что обновлений функциональности (кумулятивных обновлений) больше выпускаться не будет — только обновления безопасности.  Хотя Майкрософт говорит, что может выпускать ещё и обновления для совместимости с Office 365.

Полезные ссылки:

  1. https://blogs.technet.microsoft.com/exchange/2018/06/19/released-june-2018-quarterly-exchange-updates/
  2. https://blogs.technet.microsoft.com/exchange/2018/04/10/exchange-server-2013-enters-extended-support-lifecycle-phase/

Лечение сервера WSUS методом ожидания


С утра запустил установку обновлений  на WSUS сервере. После перезагрузки сервер перестал получать отчеты от клиентов. В логе клиента Windows 7:


2018-06-13 16:54:47:422 456 20c0 PT WARNING: ReportEventBatch failure, error = 0x8024400E, soap client error = 7, soap error code = 400, HTTP status code = 200
2018-06-13 16:54:47:422 456 20c0 PT WARNING: SOAP Fault: 0x000190
2018-06-13 16:54:47:422 456 20c0 PT WARNING: faultstring:Server was unable to process request. ---> The type initializer for 'Microsoft.UpdateServices.Internal.Reporting.WebService' threw an exception. ---> Login failed for user 'NT AUTHORITY\NETWORK SERVICE'. Reason: Server is in script upgrade mode. Only administrator can connect at this time.
2018-06-13 16:54:47:422 456 20c0 PT WARNING: ErrorCode:(null)(0)
2018-06-13 16:54:47:422 456 20c0 PT WARNING: Message:(null)
2018-06-13 16:54:47:422 456 20c0 PT WARNING: Method:(null)
2018-06-13 16:54:47:422 456 20c0 PT WARNING: ID:(null)
2018-06-13 16:54:47:422 456 20c0 Report WARNING: Reporter failed to upload events with hr = 8024400e.

Смотрим на сервере WSUS в логе C:\Windows\WID\Log\Error.log:


2018-06-13 13:54:04.64 spid17s Starting up database 'SUSDB'.
2018-06-13 13:54:04.68 spid9s Starting up database 'model'.
2018-06-13 13:54:04.87 Logon Error: 18401, Severity: 14, State: 1.
2018-06-13 13:54:04.87 Logon Login failed for user 'NT AUTHORITY\NETWORK SERVICE'. 2018-06-13 13:54:04.64 spid17s Starting up database 'SUSDB'.
2018-06-13 13:54:04.68 spid9s Starting up database 'model'.
2018-06-13 13:54:04.87 Logon Error: 18401, Severity: 14, State: 1.
2018-06-13 13:54:04.87 Logon Login failed for user 'NT AUTHORITY\NETWORK SERVICE'. Reason: Server is in script upgrade mode. Only administrator can connect at this time. [CLIENT: <named pipe>] Only administrator can connect at this time. [CLIENT: <named pipe>]

«Reason: Server is in script upgrade mode.» — и что с этим делать? Ответ — ничего! Точнее просто ждать. На моём сервере база обновилась и перешла в рабочее состояние через 5 часов.

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