Powershell 6 — изменения в Get-WinEvent Часть 2

Только я успел сообщить о том, что мне удалось устранить багу в Get-WinEvent, как была одобрена вторая часть моей работы Add support <Suppress> in Get-WinEvent -FilterHashtable в рамках проекта Open Powershell.

Теперь можно не только формировать запрос Select и выбирать события по нужным критериям, но добавлять фильтр для отсеивания событий:

$filterSuppress = @{ path = "$ystem";  SuppressHashFilter=@{Id=370}}

$resultsSuppress = Get-WinEvent -filterHashtable $filterSuppress

Powershell 6 — изменения в Get-WinEvent

Как писал ранее существует проект Open Powershell, к которому можно свободно подключиться и поучаствовать в развитии ядра Powershell. Я уже подключился — а вы?

Первые результаты моей работы:

1. Исправлен баг при обработке параметра FilterHashtable в командлете Get-WinEvent. Проблема была в том, что именованные свойства не обрабатывались корректно и командлет просто ничего не возвращал, что безусловно вводило в заблуждение (событий нет, в то время как они есть в журнале).
2. Также не обрабатывались множественные критерии поиска для именованных параметров (-FilterHashtable может принимать массив фильтров, а не один хэш)

Подробности можно найти тут Get-WinEvent with FilterHashtable generate broken query (filter) #2327 

Возможно это исправление перенесут в текущую ветку Powershell и исправление появится в одной из новых сборок Windows 10.

Open Powershell

18 августа 2016 года произошло знаменательное событие — Microsoft объявило, что Powershell теперь становится Open Source.

PowerShell is open sourced and is available on Linux

PowerShell on Linux and Open Source!

Что это означает?

1. Теперь Microsoft будет включать в свою ОС версию Powershell, которая базируется на Open Powershell.
2. Open Powershell является многоплатформенным проектом и уже работает на ряде сборок Linux и MacOS! Сегодня невозможно портировать часть функций Powershell (например, из-за отсутствия WMI, ограничений .Net и т.п.), тем не менее большая часть проекта уже портирована.
3. Проект живет на Github.com. Если вы готовы развивать проект и программировать, то вы можете свободно зарегистрироваться и включиться в работу!
   
4. Учтите, что проект включает только ядро Powershell и базовые модули: все остальное развивается как отдельные проекты, которые могут быть как открытыми, так и закрытыми. (Иначе говоря, если вы захотите включить в Open Powershell свой специфический командлет, то скорее всего вам порекомендуют разместить его на PowershellGallery.)
5. Если вы не программист, то у вас все равно есть возможность активно участвовать в развитии Powershell. Для этого есть сайт UserVoice. Регистрация простейшая – заходите, обсуждайте, комментируйте, голосуйте, создавайте свои темы. На русском языке можно писать на форуме Technet-RU. Всё это изучается командой разработчиков (и Microsoft и, теперь, комунити) и реализуется. Если вы активный пользователь Powershell, то очень рекомендую хотя бы пару раз в месяц посещать сайт UserVoice.
6. На текущей момент версия проекта Powershell 6.0 alfa. Alfa означает, что проект находится в ранней стадии. Тем не менее он работает! Вы можете скачать пакет, установить и использовать в работе. Новая alfa сборка каждые сутки.
7. Когда будет релиз 6.0? Пока сроки не установлены.

Ваш голос о Powershell

Команда разработчиков Powershell хочет услышать ваше мнение!

Для этого создан сайт UserVoice https://windowsserver.uservoice.com/forums/301869-powershell , на котором вы можете:

1. Сообщить о баге.
2. Сделать предложение по новой фиче.
3. Просмотреть уже сделанные предложения, прокомментировать их и проголосовать.

Самое главное — смотрите открытые кейсы, пишите свое мнение и голосуйте. Чем выше рейтинг кейса, тем больше шансов на скорейшее исправление проблемы или реализацию новой фичи.

Если вы нашли багу, то изучите ее, создайте примеры, поищите в Интернете сообщения на эту тему, посмотрите нет ли уже подобного сообщения на UserVoice — теперь вы готовы открыть новый кейс на UserVoice. Чем тщательней вы всё это проделаете, тем быстрее и проще будет устранить проблему.

Если вы не сильны в английском, чтобы самостоятельно создать кейс на UserVoice, то создайте тему на русском форуме TechNet-RU — коллеги обязательно вам помогут.

Remote Desktop Gateway в ресурсном лесу

Даже не подозревал, что может быть проблема, если пользователи и Remote Desktop Gateway находятся в разных лесах – пользователи не могут пройти авторизацию на шлюзе.

Ситуация и решение подробно описаны в статье https://support.microsoft.com/en-ca/kb/972133

Суть в том, что в политику CAP нужно включать только универсальные группы, а уже в них глобальные из разных лесов.