10 PowerShell-скриптов, которые экономят сисадмину несколько часов в неделю

IT-аутсорсингом для небольших компаний я занимаюсь двенадцать лет. И каждый раз, заходя в новый офис, вижу одну и ту же картину: сисадмин ходит по кабинетам с флешкой, вручную ищет установленное ПО, а уволенного сотрудника забывает заблокировать до следующего утра. PowerShell стоит на каждой машине. Никто им не пользуется. Я собрал десять скриптов, которые реально работают у наших клиентов — суммарно они экономят от двух до пяти часов в неделю.

Почему PowerShell, а не специализированные утилиты

На каждой встрече мне задают один и тот же вопрос: зачем писать скрипты, когда есть готовые инструменты? Отвечаю цифрами. Серверная лицензия SCCM — от 30 000 рублей, плюс клиентские CAL сверху. LANScope, SolarWinds, отечественные аналоги попроще — от 60 000 до 150 000 рублей в год. Для юридической фирмы на 18 рабочих мест или медклиники на 25 компьютеров это просто не окупается. Совсем.

PowerShell встроен в Windows начиная с Server 2008. Он уже есть на каждой машине — без установки, без лицензии, без лишних движений. Для задач малого офиса он закрывает примерно 80% того, что умеют платные инструменты. Я не спорю, что SCCM нужен — нужен, когда машин 500 и больше. Но платить шестизначную сумму за то, что делается скриптом за вечер, при 30–50 рабочих местах — по меньшей мере странно.

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

Скрипты 1 и 2: инвентаризация железа и программного обеспечения

Первый скрипт — и самый востребованный. Обходит все компьютеры в домене через WMI и собирает в одну таблицу: имя машины, процессор, объём оперативной памяти, серийный номер материнской платы, объём дисков, версию ОС и дату последней загрузки. Выгружает всё в CSV, который открывается в Excel без лишних манипуляций с форматом. В основе — Get-ADComputer для получения списка машин, затем Get-CimInstance с классами Win32_ComputerSystem, Win32_Processor, Win32_PhysicalMemory. Всё удалённо. Руками трогать машины не нужно.

Расскажу конкретный случай. Наш клиент — строительная компания на 35 рабочих мест — в прошлом году готовился к переходу с Windows 10, срок поддержки которой заканчивается. Нужно было быстро понять: какие машины потянут Windows 11 по железу, а какие уже пора менять. Запустил скрипт — через двадцать минут на руках полный список с процессорами, памятью и статусом TPM по каждой машине. Без скрипта сисадмин потратил бы день. Буквально день — восемь рабочих часов, которые стоят реальных денег.

Второй скрипт — реестр установленного ПО. Читает ветку HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall и аналогичную ветку для 32-битных программ с каждой машины в домене. Результат — снова CSV. Что можно увидеть: сколько копий 1С Бухгалтерия 3.0 реально установлено и совпадает ли это с числом купленных лицензий, стоит ли где-то Adobe Acrobat Pro без лицензии, не притащили ли пользователи торренты или игры. У одного клиента — бухгалтерская фирма на 18 машин — обнаружили 1С на 11 компьютерах при восьми купленных лицензиях. Разобрались до проверки. Хорошо, что до.

Скрипты 3 и 4: блокировка уволенного сотрудника за тридцать секунд

Это, пожалуй, самый критичный скрипт из всего списка. Когда сотрудник увольняется — особенно в конфликте — у вас есть буквально минуты, чтобы закрыть доступ. Стандартный ручной путь: зайти в Active Directory Users and Computers, найти учётку, отключить, убрать из всех групп, сменить пароль, записать в журнал. При аккуратной работе — минут десять. Если сисадмин занят или не сразу узнал об увольнении — полчаса, час. За это время человек успевает скачать что угодно.

Скрипт делает всё одной командой. Disable-ADAccount — отключает учётку. Move-ADObject перемещает её в OU «Уволенные». Remove-ADGroupMember в цикле по Get-ADPrincipalGroupMembership убирает из всех групп. Set-ADAccountPassword ставит случайный пароль. Set-ADUser обновляет поле Description: туда пишется дата и имя того, кто запустил скрипт. Тридцать секунд. Можно повесить на кнопку — буквально ярлык на рабочем столе у HR, который вызывает скрипт с одним параметром: логин учётной записи. Нажал, ввёл имя — готово. AD применит политики, RDP отвалится, доступ к файловым шарам закроется сам.

Четвёртый скрипт — для тех, у кого Exchange или Microsoft 365. После блокировки в AD нужно ещё отключить почтовый ящик и поставить автоответ: «этот сотрудник больше не работает в компании, обращайтесь по адресу...». Без этого клиенты продолжают писать на старый адрес, письма теряются — или, что хуже, кто-то ещё несколько дней читает почту с телефона. Скрипт использует Set-Mailbox -HiddenFromAddressListsEnabled и Set-MailboxAutoReplyConfiguration. Для Exchange On-Premises работает напрямую. Для Microsoft 365 нужен модуль ExchangeOnlineManagement — устанавливается один раз командой Install-Module.

Был у нас неприятный случай. Менеджер по продажам уволилась со скандалом и унесла базу клиентов. Доступ заблокировали только утром следующего дня — HR не сразу сообщил в IT. Теперь у этого клиента стоит жёсткое правило: как только подписан приказ, HR нажимает кнопку. Не на следующее утро. Не «как дойдут руки». Сразу. Скрипт не даёт забыть про процедуру и не требует держать в голове последовательность из шести шагов.

Скрипты 5 и 6: очистка профилей и временных файлов

Пятый скрипт закрывает хроническую боль RDS-серверов и рабочих станций — разросшиеся профили пользователей. На сервере терминалов, где работают 25–30 человек, за три года накапливаются профили давно уволенных, брошенные кеши, папки AppData на десятки гигабайт. Скрипт находит профили, которые не использовались больше 90 дней — смотрит LastLogonDate из AD, — проверяет, что учётка отключена или удалена, и только после этого удаляет профиль. Параметр -WhatIf показывает, что будет удалено, не трогая ничего реально. Первый прогон я всегда делаю в режиме симуляции. Без исключений.

Шестой скрипт попроще, но результат виден сразу. Чистит временные папки: %TEMP% каждого пользователя, C:\Windows\Temp, папку загрузок Windows Update из SoftwareDistribution\Download, при необходимости — кеш браузеров. Запускается удалённо на всех машинах через Invoke-Command. На одном RDS-сервере у клиента из юридической фирмы в первый раз освободили 47 гигабайт. Сервер работал три года без чистки, диск был занят на 91 процент. После скрипта — 68. Это стало наглядным ответом на вопрос руководства «почему сервер тормозит».

Оба скрипта пишут лог: что удалено, сколько места освобождено, на каком компьютере и в какое время. Зачем это нужно? Если кто-то скажет «вы удалили мои файлы» — есть история с доказательствами того, что удалялось только из системных временных папок, а не из папки Documents пользователя. На нашей практике такие споры случались. Один раз лог закрыл вопрос за минуту.

Скрипты 7 и 8: мониторинг дискового пространства и уведомления об истечении паролей

Седьмой скрипт мониторит свободное место на всех дисках всех серверов из заранее заданного списка. Логика прямая: свободно меньше 15% — письмо с предупреждением, меньше 5% — письмо с темой «КРИТИЧНО: диск заканчивается». Для отправки использует Send-MailMessage или Net.Mail.SmtpClient с поддержкой TLS — внешние модули не нужны. Ставится в Планировщик заданий, запускается каждые четыре часа. Настройка вместе с тестами занимает полчаса.

Именно такой скрипт спас бы нас — точнее, одного нашего клиента. Юридическая компания, файловый сервер на Windows Server 2019. В воскресенье вечером партнёр закинул на сервер 22 гигабайта архивов с документами — готовился к крупному судебному процессу. Диск заполнился под 100%. Утром в понедельник 1С не запустилась: не смогла создать временные файлы. Два часа ушло на диагностику и зачистку места — в самый неподходящий момент. Если бы скрипт работал, он поднял бы тревогу ещё в пятницу, когда диск перевалил за 80%. Было бы время разобраться без паники, а не носиться с этим в девять утра понедельника.

Восьмой скрипт решает простую, но болезненную задачу — уведомляет пользователей об истечении паролей. Search-ADAccount -PasswordExpiring с параметром -TimeSpan (New-TimeSpan -Days 14) выбирает всех, у кого пароль сгорает в ближайшие 14 дней. Каждый получает персональное письмо: «Ваш пароль в домене истекает через N дней — смените его через Ctrl+Alt+Del». Банально? Да. Но без этого по понедельникам в малом офисе телефон не замолкает: «я не могу зайти». Особенно страдают те, кто работает удалённо через VPN или RDP — стандартное предупреждение Windows до них просто не доходит. Скрипт запускается каждый день в 8 утра и делает своё дело тихо.

Скрипты 9 и 10: аудит групповых политик и история входов пользователей

Девятый скрипт — экспорт всех групповых политик в HTML-отчёт. Одна команда: Get-GPOReport -All -ReportType HTML. Зачем это нужно? Когда что-то ломается — не применяется политика, не ставится принтер, блокируется USB — первый вопрос всегда один: какие GPO вообще действуют и на что? Руками лезть в Group Policy Management Console — это час работы минимум. Скрипт генерирует тот же результат за минуту. Есть ещё один полезный приём: запускать его раз в месяц и складывать файлы в папку с датой в имени. Потом легко сравнить январь с мартом и увидеть, что изменилось. На нашей практике это не раз помогало найти причину загадочного «само сломалось» — оказывалось, кто-то тихо правил GPO без записи в журнале изменений.

Десятый скрипт показывает историю входов и выходов конкретного пользователя. Берём журнал безопасности Windows: событие 4624 — успешный вход, 4634 — выход. Get-WinEvent с фильтром @{LogName='Security'; Id=4624,4634}, плюс отбор по имени пользователя и нужному диапазону дат. На выходе — таблица: когда зашёл, с какого компьютера, каким способом — интерактивно, через RDP или по сети. Руководители периодически задают неловкий вопрос: «Иванов говорит, что работал в пятницу, а отчёт не сдал — он вообще в систему заходил?» Теперь ответ есть за тридцать секунд. Никакого разговора вслепую.

Важный нюанс, который легко упустить. Журнал безопасности на контроллере домена по умолчанию хранит всего 20 МБ событий — при активном домене это несколько дней, не месяц. Скрипт умеет работать и с архивными логами, если архивация заранее настроена. Мы обычно через GPO выставляем размер журнала Security на всех DC на 1 ГБ. При нагрузке среднего офиса этого хватает на несколько месяцев истории — и вопрос «а что было три недели назад» перестаёт быть проблемой.

Как всё это запустить: политики выполнения, права и планировщик

Первое, с чем сталкиваешься при работе с PowerShell в корпоративной среде — Execution Policy. Windows по умолчанию не запускает неподписанные скрипты. Быстрое решение: Set-ExecutionPolicy RemoteSigned -Scope LocalMachine на каждом сервере вручную. Но правильнее сделать это через GPO: Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Windows PowerShell → «Включить выполнение скриптов» → «Разрешить локальные и удалённые подписанные скрипты». Второй вариант сам разъедется по всем машинам домена — руками трогать ничего не нужно.

Второй момент — права. Большинству скриптов для чтения из AD и WMI достаточно прав Domain Users плюс членство в группе Remote Management Users на целевых серверах. Если скрипт что-то меняет — блокирует учётки, чистит профили — нужны Domain Admins или делегированные права на конкретные OU. Мой подход: создать отдельную учётную запись svc_powershell с минимально необходимыми правами и гонять все скрипты именно от неё. Не от своей учётки, не от встроенного Administrator. Тут сразу два плюса: безопасность и прозрачный аудит — в логах событий сразу видно, что изменения вносил сервисный аккаунт, а не живой человек.

Третье — Планировщик заданий. Все регулярные скрипты живут в Task Scheduler: мониторинг дисков каждые четыре часа, уведомления о паролях ежедневно в 8:00, инвентаризация по пятницам ночью. Настроить можно через GUI или командой Register-ScheduledTask прямо из PowerShell. Результаты пишутся в лог-файлы с датой в имени — diskcheck_20260628.log, inventory_20260628.csv — в сетевую папку, доступную сисадмину с любой машины. Через месяц работы уже видна картина: например, диск на файловом сервере прибавляет по 3 ГБ в неделю — значит через два месяца место кончится. Это уже не просто автоматизация. Это аналитика, которая позволяет планировать закупки заблаговременно, а не чинить в аварийном режиме.

Частые вопросы

Нужно ли покупать дополнительные модули или лицензии для этих скриптов?
Нет. Все скрипты используют только то, что входит в стандартный комплект Windows Server и RSAT — Remote Server Administration Tools. Модуль ActiveDirectory доступен бесплатно как часть RSAT, устанавливается через «Компоненты Windows» в пару кликов. Единственное исключение — если нужно управлять Microsoft 365, понадобится модуль ExchangeOnlineManagement. Он тоже бесплатный, устанавливается командой Install-Module из PowerShell Gallery.

Скрипты работают только с Active Directory или можно использовать в рабочей группе без домена?
Большинство скриптов написаны под доменную среду — там проще работать с учётными записями и удалённым управлением через WMI. Но скрипты очистки временных файлов и мониторинга дисков работают и без домена: вместо Get-ADComputer просто указываете список машин вручную. Инвентаризация тоже адаптируется — вместо запроса из AD используется заранее заданный массив имён компьютеров или IP-адресов.

Что если скрипт случайно удалит что-то важное?
Все скрипты, которые что-то удаляют или меняют, поддерживают параметр -WhatIf — стандартный механизм PowerShell, который показывает, что будет сделано, без реального выполнения. Первый запуск всегда делайте с этим параметром. Плюс для удаления профилей и файлов обязательно настройте резервное копирование — мы используем либо встроенный Windows Server Backup, либо Veeam, в зависимости от бюджета клиента. Скрипт — не замена бэкапу.

Нужен ли продвинутый уровень PowerShell, чтобы адаптировать скрипты под свой офис?
Нет. Большинство параметров, которые придётся менять — имена OU в Active Directory, адрес SMTP-сервера, список серверов для мониторинга, пороговые значения в процентах — вынесены в переменные в начале каждого скрипта с пояснениями. Базового понимания синтаксиса PowerShell — переменные, циклы foreach, условия if — достаточно, чтобы адаптировать любой из этих скриптов под свои нужды за полчаса.