Powershell проверить доступность компьютера

Как проверить, установлен ли модуль PowerShell?

Чтобы проверить, существует ли модуль, я попробовал следующее:

Я действительно получаю ошибку, но никакого исключения не возникает, поэтому в конце концов мы видим Module exists , хотя SomeModule не существует.

Есть ли хороший способ (желательно без генерации ошибки) определить, установлен ли в системе модуль PowerShell?

PowerShell: Get-ADComputer — получение данных о компьютерах в Active Directory

Справка о параметрах командлета Get-ADComputer вызывается стандартно:

Чтобы получить информацию о конкретном компьютере укажем его имя с параметром —Identity:

Get-ADComputer -Identity SRV-DB01

Нас интересует время его последней регистрации в AD, но этой информация в выводе команды нет. Выведем все свойства компьютера в Active Directory:

Get-ADComputer -Identity SRV-DB01 -Properties *

Как мы видим, время последней входа в сеть (LastLogonDate) — 0:20:17

Уберем всю лишнюю информацию, оставив только значение полей Name и LastLogonDate.

Get-ADComputer -identity SRV-DB01 -Properties * | FT Name, LastLogonDate -Autosize

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

Get-ADComputer -Filter * -Properties * | FT Name, LastLogonDate -Autosize

Чтобы вывести данные о компьютерах в определенном OU, воспользуемся параметром SearchBase:

Get-ADComputer -SearchBase ‘OU=Moscow, DC=winitpro, DC=loc’ -Filter * -Properties * | FT Name, LastLogonDate -Autosize

Отсортируем результаты запроса по времени последнего логина в сеть (поле LastLogonDate) с помощью команды Sort,

Get-ADComputer -Filter * -Properties * | Sort LastLogonDate | FT Name, LastLogonDate -Autosize

Итак, мы получили список компьютеров и время их последнего входа в домен Active Directory, теперь мы хотим заблокировать учетные записи компьютеров, не использовавшихся более 120 дней.

С помощью Get-Date получим в переменной значение текущей даты и уменьшим ее на 120 дней:

$date_with_offset= (Get-Date).AddDays (-120)

Полученную переменную с датой можно использовать в качестве фильтра запроса Get-ADComputer по полю LastLogonDate

Get-ADComputer -Properties LastLogonDate -Filter | Sort LastLogonDate | FT Name, LastLogonDate -Autosize

Таким образом, мы получили список компьютеров, не регистрировавшихся в сети более 120 дней. С помощью команды Disable-ADAccount отключим их.

Совет. В первый раз лучше протестировать результаты команды с помощью переключателя -WhatIf, благодаря которому команда не вносит никаких изменений, показывая, что произойдет при ее выполнении.

Get-ADComputer -Properties LastLogonDate -Filter | Set-ADComputer -Enabled $false -whatif

Get-ADComputer -Properties LastLogonDate -Filter | Set-ADComputer -Enabled $false

Еще несколько полезных приемов по работе с командой Get-ADComputer

Получить количество всех учетных записей компьютеров в Active Directory:

Get-ADComputer -Filter | Measure-Object

Выбрать все компьютеры с ОС Windows XP:

Выбрать только серверные системы:

Get-ADComputer -Filter < OperatingSystem -Like '*Windows Server*' >-Properties OperatingSystem | Select Name, OperatingSystem | Format-Table -AutoSize

Результаты выполнения команды можно выгрузить в текстовый файл:

Get-ADComputer -Filter < OperatingSystem -Like '*Windows Server*' >-Properties OperatingSystem | Select Name, OperatingSystem | Format-Table -AutoSize C:Scriptserver_system.txt

Get-ADComputer -Filter * -Property * | Select-Object Name, OperatingSystem, OperatingSystemServicePack | Export-CSV All-Windows.csv -NoTypeInformation -Encoding UTF8

Три запроса PowerShell для получения важной системной информации

Ниже приводятся три сценария, позволяющие получить некоторую информацию о клиентских и серверных машинах под управлением Windows. Сценарии созданы на базе PowerShell 2 и могут применяться к клиентским системам, начиная от Windows XP и выше, а также к серверам под управлением Windows Server 2003 и выше. Для использования PowerShell 2 рекомендуется установить Windows PowerShell PowerPack.

1. Определение исходного разрешения экрана

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

Рисунок A

Эта команда PowerPack на данный момент не поддерживает работу с удаленными системами, что ограничивает возможности ее использования в обширных компьютерных сетях. В таком случае можно осуществить установку PowerPack при помощи групповой политики и выполнять команду на всех компьютерах локально. К ней также стоит добавить переменную для определения имени компьютера и записи данных в файл на локальной или удаленной системе:

2. Перечисление USB-устройств

Выяснить, какие USB-устройства подключены к системе, порой бывает не так-то просто. Системные администраторы проклинают тот день, когда производители компьютеров решили использовать USB вместо PS/2 для клавиатур и мышей. Ведь гораздо проще было бы применять общую политику для всех USB-устройств, не затрагивая средства ввода, подключенные через PS/2. Получить список USB-устройств, подключенных к серверу или рабочей станции, можно с помощью модуля PowerShell Get-USB. Пример вывода команды показан на рис. B. В строке «Заголовок» (Caption) значится «Blue Snowball» — это подключенный к системе микрофон.

Рисунок B

Таким способом администратор может получить список всех подключенных к компьютеру USB-устройств для последующего ограничения доступа к оборудованию. Сведения о подключенных USB-накопителях можно использовать при аудите политик.

В отличие от команды, описанной в первом пункте, этот сценарий можно без дополнительной подготовки использовать для сбора данных на удаленных системах. При использовании переменной -computername команда подключается к удаленному компьютеру и выдает те же результаты, которые могли бы быть получены при локальном выполнении. При этом на удаленные системы не нужно устанавливать PowerShell PowerPack, что весьма удобно. Полная команда приводится ниже:

3. Получение подробных сведений о процессоре

В наши дни инвентаризация процессоров на серверах, рабочих станциях и виртуальных машинах может стать довольно непростой задачей. Команда PowerShell Get-Processor позволяет централизованно получить информацию о количестве процессоров и процессорных ядер, доступных системе. Пример вывода команды показан на рис. C.

Рисунок C

В этом примере виртуальная машина располагает одним процессором, для которого указана модель и частота. Если опустить параметр -Computer, вывод команды будет включать результаты только для локальной системы. Для разных процессорных конфигураций выводятся разные сведения, сравнимые с теми, что можно получить при помощи традиционных утилит типа CPUID .

В аптечку администратора

Описанные сценарии позволяют администратору получить необходимый минимум информации о компьютерной рабочей среде. А какими функциями PowerShell для инвентаризации пользуетесь вы? Поделитесь своим опытом в комментариях!

Автор: Rick Vanover
Перевод SVET

Оцените статью: Голосов

Copyright © 2006-2022 Winblog.ru All rights reserved.
Права на статьи принадлежат их авторам. Копирование и использование материалов разрешается только в случае указания явной гиперссылки на веб-сайт winblog.ru, как на источник получения информации.
Сайт для посетителей возрастом 18+

Просмотр всех установленных приложений с помощью PowerShell

Чтобы просмотреть список всех установленных приложений с помощью PowerShell, выполните следующие действия:

1. Откройте Пуск в Windows 10.
2. Найдите PowerShell, щелкните правой кнопкой мыши верхний результат и выберите параметр Запуск от имени администратора.
3. Введите следующую команду, чтобы просмотреть список установленных приложений, и нажмите Enter:

Когда вы выполните эти шаги, вы увидите список со всеми приложениями Microsoft Store, установленными в Windows 10.

Powershell проверить доступность компьютера

Примечание: данный пост перепечатан в связи с закрытием бложиков на spaces.live.com, как имеющий какую-то ценность для автора и/или читателей.

Ричард Сиддэвей (Richard Siddaway) в своём блоге ведёт на мой взгляд интересный цикл постов Windows 2000 Scripting Guide (W2KSG) с применением PowerShell и WMI. В них рассказываются достаточно интересные и полезные возможности классов WMI для сбора различных сведений как программной части системы, так и аппаратной. Так же недавно на форуме TechNet была поднята (да, на форумах всегда найдутся археологи, которые выкопают темы полу- и годичной давности, а то и ещё старше 🙂 ) тема про скрипт, который бы собрал данные об аппаратной составляющей компьютеров. Подобные темы периодически всплывают на различных форумах. Я подумал, что неплохо было бы решить данный вопрос с помощью PowerShell.

Итак, отправной точкой для меня послужила ссылка на Computer System Hardware Classes, где я посмотрел какие классы можно применить. Изучив весь список я отобрал лишь самые необходимые для решения задачи классы, а именно:

Достаточно сходить по ссылкам и можно посмотреть множество свойств каждого класса, которые детально описывают себя. Но при прочтении очень важно следить за поддерживаемыми свойствами в ОС, которые были выпущены до Windows Vista/2008. Я старался эти моменты учитывать, чтобы получить оптимальную совместимость как с предыдущими ОС, так и с текущими.

Ничего сверхсложного в этом нету, сперва я определил требуемые классы WMI в переменные и определил набор необходимых свойств каждого класса следующим образом:

После определения всех классов WMI и переменных я начал писать секцию вывода. Например, вывод имени компьютера и ОС, под которой он управляется:

Здесь можно не обращать на знаки регулярных выражений, т.к. они несут только одну функцию, а именно — удобное для воспроиятия форматирование вывода. Т.е. первой строкой пойдёт название поля Computer Name, после чего будет переход на новую строку (`n). Чтобы все строчки не сливались я значения полей отделил табулятором (`t). И в конце так же добавил знак возврата каретки (`n), чтобы отделить между собой поля. Вывод в данном случае будет таким:

Т.е. поля идут с левого края и между собой отделены двумя пустыми строками. А значения полей отделены табулятором относительно того же левого края. Мне кажется, что такой выход весьма читабелен и данные не сливаются в кучу. Когда у поля только одно значение — всё просто. Но когда значений возможно несколько, то задача форматирования выхода таких данных стала для меня небольшой проблемой. Почему небольшой — потому что ответ посмотрел в блоге у Ричарда, а именно в посте W2KSG: Free Disk Space. Суть заключается в очень простом: берётся переменная с массивом данных и по конвейеру при помощи команды Format-Table подготавливается табличный выход и с указанием основного элемента, по которому будет этот выход формироваться. Чтобы лучше понять этот процесс я покажу его на примере вывода сведений о процессоре. Сейчас многопроцессорные системы не редкость и скрипт должен поддерживать показ сведений о более чем одном процессоре:

К сожалению, ноутбук у меня однопроцессорный, поэтому эту часть скрипта я запустил на стационаре (в котором, кстати, тоже только 1 физический процессор. Но технология Hyper-Threading эмулирует именно настоящую мультипроцессорность, а не логические ядра, как это сделано в многоядерных процессорах). Итак, давайте разберём строку:

Переменная $CPU содержит сведения о всех установленных процессорах в системе. Я эту переменную передал по конвейеру сразу на команду форматирования — ft (сокращённый алиас от Format-Table) и указал по какому свойству форматировать (DeviceID, который перечисляет ID номера всех процессоров начиная с 0). А дальше я использовал несколько хэш-таблиц для отображения дополнительных свойств каждого объекта. Параметр Label задаёт название новой графе, а Expression указывается значение параметра (как Architecture и Model). Если посмотреть справку по классу Win32_Processor, то можно увидеть, что свойство Architecture содержит лишь числовое значение (от 0 до 9) и в справке приведена расшифровка этих значений. Числовые значения в данном случае, согласитесь, не самый читабельный вариант. Поэтому в Expression я вместил конструкцию Switch, которая автоматически будет числовым значениям сопоставлять понятные текстовые значения. И если свойство Architecture вернёт числовое значение 0, то Switch в нашем случае сопоставит ему более понятное значение x86. И в последней строке я добавил ещё одну хэш-таблицу, которая добавляет ещё одну графу — Model, которая будет содержать свойство Name класса Win32_Processor — название процессора.

Такое форматирование выхода я делал для каждого поля, которое может содержать несколько значений. Например, объём каждого установленного модуля памяти:

DeviceID будет содержать номер каждого установленного модуля памяти начиная с нулевого ряда (разбор понятий Ряд и Банк памяти выходит за рамки данного поста) или первого слота. StartingAddress и EndingAddress показывают адресное пространство, за которое отвечает каждый модуль начиная от первого байта. И простым вычитанием начального адреса из конечного мы получим ёмкость каждого модуля:

Так же, как и с процессорами я содержимое переменной $RAM перенаправил по конвейеру на форматирование по столбцу DeviceID. И через запятую добавил ещё одну хэш-таблицу, которая будет показывать объём каждого модуля. Если просто произвести операцию вычитания, то мы получим объём памяти в килобайтах. Чтобы показать объём в мегабайтах я просто разделил полученную разность на килобайты — 1KB (Очень удобная штука 🙂 ). Здесь важно было не ошибиться, т.к. по логике может показаться, что нужно делать на 1MB, чтобы получить размер в мегабайтах. Но, как я уже сказал выше, у нас разность будет уже в килобайтах. Поэтому, чтобы получить в мегабайты, то нам нужно разделить только на 1KB. И посмотрим, что мы будем иметь на выходе:

Вот так мы получили номера модулей памяти и объём каждого из них. После деления у нас не получится целое число, поэтому я сконвертировал это число в строку (ToString) и указал количество знаков после запятой — 0 знаков (F00). В данном случае дробное число просто округляется до ближайшего целого числа. Количество знаков после запятой можно изменить, например указав F01, которое округлит число до ближайшего целого числа с точностью до 1 знака после запятой. Это всё не я придумал, а честно взял из поста W2KSG: Free Disk Space 🙂

Вот, в принципе, я рассказал о всех используемых в скрипте приёмах, которые доступны в PowerShell и при дальнейшей разработке скрипта я только выдёргивал нужные свойства каждого класса и формировал более-менее приличный и понятный вывод. Хотя в итоге я добавил ещё 2 вещи:

1. Оформил скрипт в функцию Get-HwInfo и с возможностью передачи в неё имён компьютеров
2. Каждый WMI класс позволяет собирать сведения не только с локальных комьютеров, но и с удалённых. Имя далённого компьютера указывается через параметр -ComputerName при вызове команды Get-WMIObject, например: $CPU = gwmi Win32_Processor -ComputerName $computers | Select Architecture, DeviceID, Name

Таким образом извне можно подавать в функцию имена компьютеров (например, из текстового файла со списком имён компьютеров), что значительно расширяет функциональность скрипта. Ну и финальный скрипт:

Здесь видно, что в конце я снова применил конструкцию Switch, которая расшифровывает числовое значение статуса сетевого адаптера в его текстовое значение.

Согласен, что скрипт выглядит не очень опрятно, но в PowerGUI он выглядит вполне сносно. На основе данного скрипта каждый может его с лёгкостью расширить и изменить под свои нужды, я лишь старался показать образец решения задачи, а так же показал некоторые интересные приёмы в PowerShell. Кстати говоря, данный скрипт можно отправить в HTML формат командой ConvertTo-Html. Это будет удобно, когда потребуется собрать подобные сведения с нескольких компьютеров. Тогда HTML формат будет весьма полезен для последующего анализа. На сегодня всё, а теперь спать.

Categories: PowerShell
Posted at: 14.10.2008 15:33 (GMT+3) by Vadims Podāns | Permalink | Comments (0)

7 комментариев »

Спасибо автору, выручил. Только у меня была проблема: «True» которая хранится в $isfile не равна строчной «True». решилось просто добавлением строки:
[string]$isfile = $(Test-Path $fpath)

Комментарий by Maks — 04.12.2018 @ 15:57

Убейте автора поста! Кто так пишет?
Во первых: Test-Path $fpath возвращает значение $True или $False, но не «True» и не «False»
Во вторых: команда IF не нуждается в сравнении с $true или $false.
Правильная строка сравнения будет:
if ($isfile) Write-host «Файл существует»
>
else Write-host «Файл не существует»
>

Комментарий by Scorpion — 15.02.2019 @ 15:03

Спасибо за более корректный код! Вообще, когда вижу свою исходники 2-3 летней давности, то прям ругаю себя. Этому посту уже более 4 лет, тогда с PowerShell я только знакомился.

Комментарий by Alexey — 27.02.2019 @ 13:05

Автор — чудак на букву М, код — НЕРАБОЧИЙ!НЕРАБОЧИЙ!НЕРАБОЧИЙ!НЕРАБОЧИЙ!НЕРАБОЧИЙ!НЕРАБОЧИЙ!НЕРАБОЧИЙ!
Как правильно заметил комментатор выше — там логическое Истина/Ложь, которое некорректно сравнивать со строкой
if (!(Test-Path $fpath)) — так будет работать.
Из-за этой говностатьи потратил полчаса пытаясь понять какого Х оно не работает, с приличного же вроде сайта копирнул.

Комментарий by Станислав — 25.04.2020 @ 20:47

Целых полчаса! ужас!
Я за 6 лет уже забыл, что там писал.
Вообще странно, что так ценящий время не знает английского

Комментарий by Alexey — 21.05.2020 @ 15:37

А где в примере, собственно, Test-Path? ¯_(ツ)_/¯

Комментарий by Читатель — 31.07.2020 @ 15:14

Непонятно, что такое $isfile и каким образом он определяет, есть файл или нет.