PowerShell Core достиг фазы Beta.1


Развитие PowerShell Core успешно продолжается. Продуктовая группа к началу конференции Build 2017 выпустила PowerShell Core Beta.1.

Эту версию вы можете свободно скачать, установить и даже применять на практике. Было бы даже очень полезно попробовать её в своей ежедневной работе и написать свои замечения разработчикам, или даже что-то исправить самому — проект же открытый!

Всё ещё существует множество проблем, которые нужно решить. Почитайте v6.0.0-beta.1 release of PowerShellCore.

Например, внезапно, Beta.1 не работает на Windows 7 SP1. Причина банальна: PowerShell Core был переведен на .Net Core 2.0, где большое количество устаревшего API просто нет.

.Net Core 2.0 также находится в стадии активной разработки, поэтому с каждым днём всё больше API портируется на Unix и добавляется в поддержку. Вы можете опробовать .Net Core 2.0 в своих проектах и написать разработчикам свои замечания или принять участие в исправлении проблем — проект .Net Core 2.0 также открытый.

Надо особо отметить, что перевод PowerShell Core на .Net Core 2.0 расширил совместимость со старыми модулями: некоторые из них могут, внезапно, начать работать в Beta.1.

Теперь стало возможно разрабатывать универсальные для всех поддерживаемых платформ модули. Те, кто ранее разрабатывал модули для Windows PowerShell, могут начать работы по «портированию» своих продуктов. Документация готовится.

Исправлено множество нюансов при работе с файловыми системами на разных платформах. Работа в этом направлении продолжается. Было бы прекрасно получить замечания от сообщества уже сейчас, потому что реального опыта использования PowerShell на различных платформах пока ещё очень мало — поделитесь своим опытом и своими потребностями с разработчиками PowerShell.

В Beta.1 вы также обнаружите, что поправлена кодировка при работе с консолью: на Windows это теперь работает точно также как в Windows PowerShell. На Unix используется Utf8 (без BOM). Это обеспечивает хорошую обратную совместимость на Windows, но оставляет открытым вопрос о будущем: например, команда разработки Windows Console проводит большую работу по развитию консоли Windows и поддержке unicode-ных приложений. В тоже время нужно обязательно сохранить обратную совместимость и обеспечить работу существующих приложений.

Открытым остаётся вопрос по использованию кодировок при работе с файлами. Windows давно и полностью использует вариант Unicode Utf16LE с BOM, в то время как Unix применяет Utf8 без BOM. Сейчас продолжается большая и важная дискуссия по поводу использования кодировок в PowerShell Core — примите участие! Вопрос не так прост, как кажется на первый взгляд, поэтому ваше мнение важно для разработчиков.

 

О пользе -noprofile в PowerShell


В PowerShell есть параметр командной строки «-noprofile», который исключает загрузку пользовательских конфигурационных файлов.

В некоторых случаях нам не следует забывать использовать этот параметр. Например, при запуске скриптов в планировщике. Даже для пользовательских скриптов плохо зависеть от внешних непредсказуемых настроек. Если же речь идет о системных скриптах, то использование параметра «-noprofile» становится критически важным: злоумышленник может внедриться в системные скрипты и натворить плохих дел.

Изменение порта RD Gateway


Если хотите сильно «зашифроваться», то в принципе возможно изменить рабочие порты (TCP и UPD) RD Gateway. Изменения придется внести на самом сервере RD Gateway, на шлюзе публикации и в клиенте (или на ферме, где динамически формируется rdp-файл. Как это сделать описано по ссылке.

 

Быстрая загрузка обновлений в Windows 10


С выходом Windows 10 Creator компания Microsoft продолжила оптимизацию установки обнвлений и вернула быструю загрузку (Express download) обновлений.

Мы уже знакомы с ней — в WSUS быстрая загрузка поддерживалась многие годы. Суть быстрой загрузки в том, что клиент загружает не полный пакет обновления, а только нужную часть, которая может оказаться значительно меньше полного пакета. Это ускоряет загрузку и экономит место на диске. С учётом того, что сейчас обновления занимают по несколько гигабайт, «новшество» выглядит очень полезным. (Обновление до версии Creator с предыдущего preview у меня выглядело как перезагрузка вместо часовой переустановки системы. Если это станет правилом для последующих обновлений, то это будет замечательно.)

Теперь эта оптимизация работает не только на WSUS, но и на SCCM и Windows Update для последних версий Windows 10.

Корпоративные клиенты уже давно могут использовать преимущества BranchCache  для загрузки обновлений. В Windows 10 появилась Delivery Optimization, которая в отличие от Branch Cache позволила использовать внешние (находящиеся в Интернет) клиенты Windows 10 для загрузки обновлений.

Подробности в документации.

 

Exchange 2013 — Authenticated SMTP relay


Редкая конфигурация, когда нужно пересылать в мир почту из небольших автономных офисов через центральный узел с использованием аутентификации на SMTP. Тем не менее кому-то может пригодится.

Суть в том, что в отличие от Exchange 2010 в Exchange 2013 не достаточно включить аутентификацию на коннекторе получения «Default Frontend» — нужно еще добавить права на коннекторе «Client Proxy», потому что подключения такого рода чудесным образом с первого коннектора направляются на второй!

Подробности Authenticated SMTP relaying in Exchange 2013

Exchange 2016 — Вопрос о размере сектора


Не секрет, что Exchange Server 2016 сильно оптимизирован для работы с дисками. И работа с дисками постоянно совершенствуется. Тоже самое касается сетевого трафика. Например, в последних версиях не реплицируются индексы, а перестраиваются прямо на пассивной копии.

Несмотря на большую проделанную работу вопросы всё еще остаются. Например, сейчас нужно обязательно использовать одинаковый размер секторов на всех дисках DAG, иначе вы получите проблемы, причем скрытые, что особенно не приятно.

Powershell – END {} это важно!


При написании командлетов (cmdlet) и расширенных функций (advanced function) нужно соблюдать определённые правила.

Вот одно такое правило:

Основная логика (вывода результатов) должна быть помещена в END {} (или Endprocessing для C#)

Если не следовать этому правилу, то мы можем получить причудливые результаты. Один из разработчиков Powershell Jason Shirk продемонстрировал это следующим примером:

PS C:\>function BeginMarlezonBalet { end { write-host 'Первая часть марлезонского балета!'}}
PS C:\>function EndMarlezonBalet { begin { write-host 'Вторая часть марлезонского балета!'}}
PS C:\>BeginMarlezonBalet | EndMarlezonBalet

Вторая часть марлезонского балета!
Первая часть марлезонского балета!