👋 Привет, админы!

Сегодня расскажу про один кейс, который недавно словил на одном из файловых серверов. Пользователи начали жаловаться, что не могут открыть файлы по SMB — «доступ запрещен», хотя права вроде бы на месте.

📌 В Event Viewer (журнал Security) увидел кучу записей с кодом ошибки 0xc000006d (STATUS_LOGON_FAILURE). А рядом — ещё интереснее: Audit Failure, Logon Type 3, учетка domain\username.

🔥 Оказалось, что проблема была в сбитом времени на сервере — он отставал на 6 минут от контроллера домена. Из-за этого Kerberos-билеты считались просроченными, и аутентификация тупо ломалась.

📎 Решение:
1. Проверил текущую синхронизацию времени:

   w32tm /query /status
   

2. Перезапустил службу времени и указал правильный NTP:

   w32tm /config /manualpeerlist:"time.windows.com,0x9" /syncfromflags:manual /reliable:yes /update
   Restart-Service w32time
   

3. Синхронизировал вручную:

   w32tm /resync /force
   

✅ После этого всё заработало, ошибки исчезли, пользователи успокоились.

💬 А у вас были проблемы из-за времени? Как организуете NTP в своей инфраструктуре — отдельный сервер, групповые политики или доверяете AD?

👉 @win_sysadmin

Как я автоматизировал очистку Temp на всех ПК в домене

Иногда кажется, что папка %TEMP% — это черная дыра. Пользователи жалуются на тормоза, места на диске мало, а ты заходишь туда — и видишь архивы обновлений, временные файлы Office, кэш инсталляторов и прочий мусор за последние сто лет.

Руками чистить на каждом ПК? Нет уж. Я сделал это через PowerShell и GPO.


Решение:
Скрипт для очистки временных файлов запускается через планировщик задач от имени SYSTEM, раз в неделю. Вот пример скрипта:

$TempPath = "$env:TEMP"
Get-ChildItem -Path $TempPath -Recurse -Force -ErrorAction SilentlyContinue |
    Where-Object { -not $_.PSIsContainer -and $_.LastWriteTime -lt (Get-Date).AddDays(-7) } |
    Remove-Item -Force -ErrorAction SilentlyContinue

Чтобы запускался на всех компах в домене:
1. Создал GPO с task scheduler (Computer Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks)
2. Указал Action: Create, Run as: SYSTEM, триггер раз в неделю.
3. В Program/noscript указал powershell.exe, а в аргументах:
-ExecutionPolicy Bypass -File \\ваш-сервер\netlogon\clean_temp.ps1

Важно:
– Скрипт не трогает свежие файлы (новее 7 дней)
– Работает бесшумно, ничего не спрашивает
– Можно дополнительно чистить C:\Windows\Temp, если уверены


Вывод:
Не запускайте такую штуку в logon-скриптах — это затормозит вход в систему. Лучше использовать планировщик задач. И, конечно, тестируйте сначала на паре машин — на всякий случай.

👉 @win_sysadmin

🧾 Суточный отчёт по пользователям Active Directory

📆 Выполняется автоматически через планировщик задач раз в сутки.

🔍 Скрипт собирает статистику:
- 👥 Общее количество пользователей
- ✅ Сколько активных
- ⚙️ Сколько служебных (без фамилии)
- 🔒 Сколько заблокированных
- 🆕 Сколько новых за последние сутки

📜 Пример кода на PowerShell:

$Date = Get-Date -Format "dd MMMM yyyy HH:mm"
$AllUsers = (Get-AdUser -Filter * | ?{$_.name -notmatch 'Healthmailbox'}).count
$ActiveUsers = (Get-ADUser -Filter {Enabled -eq $true} | ?{$_.name -notmatch 'Healthmailbox'}).count
$DisabledUsers = (Get-ADUser -Filter {Enabled -eq $false} | ?{$_.name -notmatch 'Healthmailbox'}).count

$StartDate = (Get-Date).AddDays(-1)
$EndDate   = (Get-Date).AddDays(+1)
$Zapros = Get-ADUser -Filter * -Properties Created | Where-Object {$_.Created -gt $StartDate -and $_.Created -le $EndDate}
$NewUsers = ($Zapros).count
$WhoUsers = $Zapros | ForEach-Object { $_.Name }

$NotSurname = Get-ADUser -Filter "Enabled -eq '$true' -and Surname -notlike '*' -and Name -ne 'Healthmailbox'"
$NotFIO = ($NotSurname).count

$Message = "На $Date в ActiveDirectory всего пользователей $AllUsers из них: `nАктивных: $ActiveUsers из них служебные: $NotFIO. `nЗаблокированных: $DisabledUsers. `nНовых пользователей: $NewUsers `r`n`r`n$WhoUsers"
$Message | Out-File -FilePath "C:\temp\$(Get-Date -Format 'dd MMMM yyyy')-UsersAD.txt"

📂 В результате получаем .txt-файл с ежедневной статистикой, сохраняемый в C:\temp.


👉 @win_sysadmin

👋 Привет, админы!

Сегодня хочу поделиться полезным трюком, как отслеживать подключения к RDP — кто, когда и откуда логинился на сервер. Это особенно актуально, если вы не используете полноценный SIEM, но хотите держать руку на пульсе.

🔍 Используем журнал событий и PowerShell:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
Where-Object { $_.Properties[8].Value -eq '10' } |
Select-Object TimeCreated,
              @{Name='User';Expression={$_.Properties[5].Value}},
              @{Name='IP';Expression={$_.Properties[18].Value}} |
Sort-Object TimeCreated -Descending | Out-GridView

📌 Что делает скрипт:
- Ищет события успешного входа (4624),
- Фильтрует по типу логина 10 (удалённый интерактивный — это RDP),
- Показывает дату, пользователя и IP-адрес источника.

Очень удобно запускать на сервере и быстро проверять, кто заходил и когда. Можно адаптировать для логгера или отправки уведомлений.

💬 А вы мониторите RDP-сессии? Используете сторонние утилиты или всё на PowerShell? Делитесь своим опытом в комментах!

👉 @win_sysadmin

👋 Привет, админы!

Недавно наткнулся на проблему: на одном из серверов резко перестали запускаться определённые задачи в планировщике. Логов — тьма, копаться через GUI — мука. Решил быстро отфильтровать нужные записи через PowerShell.

🔥 Вот универсальный скрипт для выборки событий по Event ID, источнику и ключевому слову:

Get-WinEvent -LogName "System" -FilterHashtable @{
    Id = 1074
    ProviderName = "USER32"
    StartTime = (Get-Date).AddDays(-7)
} | Where-Object { $_.Message -like "*shutdown*" } | Format-Table TimeCreated, Id, ProviderName, Message -AutoSize

📌 Что делает этот скрипт:
- Ловит события ID 1074 (завершение работы/перезагрузка).
- Источник — USER32.
- За последние 7 дней.
- Фильтрует по слову shutdown в сообщении.
- Красиво выводит таблицу.

Так можно подстроить фильтры под любой лог и быстро выцепить нужное. Особенно помогает, когда ищешь нестандартные сбои или автоматические ребуты.

💬 А вы как работаете с журналами? Есть ли свои любимые команды или утилиты? Делитесь в комментариях!

👉 @win_sysadmin

👋 Привет, админы!

Недавно столкнулся с ситуацией: на одном из серверов какая-то служба не могла достучаться до SMB-шары. Сначала думал — сетевые проблемы, потом — DNS. Оказалось, у службы просто не было прав на доступ.

🔥 Чтобы быстро проверить, может ли конкретный пользователь (или служба) получить доступ к сетевому ресурсу, использую такую команду:

$cred = Get-Credential  
Test-Path -Path "\\сервер\шара" -Credential $cred

Эта команда спросит логин/пароль и проверит, может ли указанный пользователь открыть сетевую шару. Удобно, когда нужно протестировать доступ от имени сервиса, скрипта или другого доменного аккаунта.

✅ Работает и для UNC-путей, и для доступа к административным шарам (\\server\C$). Экономит кучу времени, особенно при разборе проблем с GPO, скриптами входа и бэкапами.

💬 А вы как проверяете доступ к шарам от имени других пользователей? Есть свои лайфхаки?

👉 @win_sysadmin

👋 Привет, админы!

Сегодня хочу поделиться реальным кейсом, который меня недавно выручил. Понадобилось быстро проверить последние обновления Windows на группе серверов — вручную лезть на каждый было бы долго и больно.

🔥 Вот скрипт на PowerShell, который я использовал:

Invoke-Command -ComputerName (Get-Content C:\servers.txt) -ScriptBlock {
    Get-HotFix | Sort-Object -Property InstalledOn -Descending | Select-Object -First 5
} -Credential (Get-Credential)

✅ Что делает скрипт:
- Берет список серверов из файла servers.txt.
- Подключается к каждому по WinRM.
- Выводит 5 последних установленных обновлений.

Очень удобно, особенно когда нужно быстро убедиться, что патчи за этот месяц действительно накатились.

💬 А как вы автоматизируете проверку обновлений на парке машин? Используете WSUS, Intune, скрипты или что-то своё? Делитесь опытом!

👉 @win_sysadmin

👋 Привет, админы!

Сегодня хочу поделиться реальным кейсом из недавней практики. У нас один Windows Server 2019 внезапно перестал применять групповые политики, причем только для некоторых пользователей. Перезапуск gpupdate /force ничего не давал, а в логах висела ошибка "The processing of Group Policy failed. Windows attempted to read the file \\domain.local\sysvol\..." с кодом 1355.

🔥 Решение оказалось простым, но не сразу очевидным: проблема была в DNS!

Проверил настройки сетевого подключения — и оказалось, что в DNS стояли публичные адреса, а не наши контроллеры домена. Из-за этого сервер не мог найти свой DC.

📋 Быстрое исправление:
1. Настроил правильные DNS сервера на интерфейсе (IP адреса контроллеров домена).
2. Очистил кэш DNS:

   ipconfig /flushdns
   

3. Перезапустил сетевые службы:

   Restart-Service -Name "Dnscache","Netlogon","Kdc"
   

4. И только потом сделал:

   gpupdate /force
   

После этого политики применились без ошибок!

✅ Вывод: при любых странностях с доменом сначала проверяйте DNS. В 80% случаев проблема именно там.

💬 А у вас были случаи, когда на ровном месте DNS ломал весь домен? Поделитесь историями в комментариях!

👉 @win_sysadmin

👋 Привет, админы!

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

🧹 Нашёл удобный способ через PowerShell:

Get-ADGroup -Filter * -Properties Members | Where-Object { -not $_.Members } | Select-Object Name

📌 Эта команда:
- перебирает все группы в домене,
- вытаскивает свойство Members,
- фильтрует те, у которых оно пустое.

Результат — чистый список групп без участников. Удобно использовать перед тем, как массово удалять старые объекты или приводить в порядок права.

⚠️ Только осторожно — иногда пустые группы используются в GPO или для делегирования прав. Так что перед удалением лучше проверить связи через Get-ADGroupMember и Get-GPOReport.

💬 А вы как боретесь с наследием AD? Пишите, делитесь скриптами и опытом!

👉 @win_sysadmin

👋 Привет, админы!

Сегодня расскажу про один неожиданный баг, с которым столкнулся на Windows Server 2022. После обновлений сервер перестал пускать пользователей по RDP. Ошибка — классическая: "The connection was denied because the user account is not authorized for remote login." Хотя у юзеров были все нужные права. 🤔

🔍 Копнул глубже — выяснилось, что в группе Remote Desktop Users внезапно исчезли все пользователи. Но в GPO права были заданы верно! Оказалось, что одно из обновлений сбросило локальные группы при конфликте с групповыми политиками.

💡 Решение:

1. Проверил GPO через gpresult /h report.html — нужные настройки есть.
2. Добавил пользователей обратно в группу через PowerShell:

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\username"

3. Чтобы автоматизировать проверку и добавление нужных участников — вот мини-скрипт:

$users = @("DOMAIN\user1", "DOMAIN\user2")
foreach ($u in $users) {
    if (-not (Get-LocalGroupMember -Group "Remote Desktop Users" -Member $u -ErrorAction SilentlyContinue)) {
        Add-LocalGroupMember -Group "Remote Desktop Users" -Member $u
        Write-Host "$u добавлен в Remote Desktop Users"
    }
}

🧩 Важно: если на сервере действует GPO, которая перезаписывает локальную группу RDP Users — добавление вручную не поможет, всё снова очистится при следующем применении политики. В таком случае правьте GPO или используйте Restricted Groups/Group Policy Preferences.

❓А у вас были кейсы, когда политики втихаря ломали RDP-доступ? Как отслеживаете такие конфликты?

👉 @win_sysadmin

👋 Привет, админы!

Сегодня расскажу про один недокументированный нюанс с задачами в Планировщике Windows, с которым недавно столкнулся сам. Был у меня скрипт, который по расписанию должен запускаться от имени системной учетной записи (SYSTEM). Всё настроено правильно, вручную запускается — работает. Но вот по расписанию не срабатывает. Без ошибок, без логов, просто тишина. 🤔

🔍 После копания выяснилось: если задача запускается от SYSTEM, но в свойствах включена опция "Запускать только при входе пользователя", — она НЕ выполнится, потому что SYSTEM не входит в систему в классическом понимании.

💡 Решение:

1. Зайти в свойства задачи.
2. Переключить опцию на: "Выполнять вне зависимости от входа пользователя".
3. Обязательно включить галку "Не сохранять пароль", если используете обычную учетку (для SYSTEM это не критично).

📌 Ну и по возможности включайте логирование в задаче — пусть пишет вывод скрипта в файл, так проще отлавливать подобные "невидимые" фейлы.

💬 А у вас были странности с Task Scheduler? Может, знаете ещё тонкости, о которых стоит рассказать? Делитесь в комментариях!

👉 @win_sysadmin

🛡️ Привет, админы!

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

🔥 Встречайте команду:

(secedit /export /cfg C:\temp\secpol.cfg) > $null
Get-Content C:\temp\secpol.cfg | Where-Object {$_ -match "Password|Lockout|Audit"} 

Что делает скрипт:

* secedit /export выгружает локальную политику безопасности в текстовый файл.
* Get-Content парсит его.
* Where-Object фильтрует строки по ключевым словам: парольная политика, блокировки, аудит.

📋 Пример вывода:

PasswordComplexity = 1
MinimumPasswordLength = 12
AuditLogonEvents = 3
LockoutBadCount = 5

Это простой и быстрый способ проверить настройки перед аудитом или при подозрении на расслабленные политики.

💬 А вы как мониторите безопасность локально? Используете ли secedit, LGPO.exe, или уже всё через Intune и Defender for Endpoint?

👉 @win_sysadmin

👋 Привет, админы!

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

🔥 Скрипт на PowerShell для удаления логов старше N дней:

$LogPath = "C:\Logs"
$DaysToKeep = 30

Get-ChildItem -Path $LogPath -Recurse -Include *.log |
    Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$DaysToKeep) } |
    Remove-Item -Force

✅ Что делает:

* Ищет все .log файлы в указанной директории (и подпапках).
* Удаляет те, что старше 30 дней.

📌 Можно засунуть в Task Scheduler, чтобы запускалось раз в неделю — и забыть про ручную уборку мусора.

💬 А как вы наводите порядок в логах? Используете ротацию (logrotate на Linux, например) или автоматизируете всё через PowerShell, bash, или какой-то агент?

👉 @win_sysadmin

👋 Привет, админы!

На днях пришлось разбираться с проблемой: Windows Server перестал пинговать шлюз, хотя сам по себе был доступен по RDP, и службы работали. Первая мысль — сетевые настройки, но всё вроде норм.

🔍 Решение оказалось неочевидным: таблица маршрутизации Windows словила дичь после отключения и повторного включения второго сетевого интерфейса.

✅ Вот как я быстро проверил и подчинил ситуацию через PowerShell:

1. Смотрим таблицу маршрутов:

route print

Если видите, что маршрут к 0.0.0.0/0 уходит через нерабочий интерфейс — bingo.

2. Удаляем кривой маршрут:

route delete 0.0.0.0

3. Добавляем правильный маршрут к шлюзу:

route add 0.0.0.0 mask 0.0.0.0 <Gateway-IP> metric 10 if <Interface-Index>

Интерфейс можно узнать командой:

Get-NetIPConfiguration | Select-Object InterfaceAlias, InterfaceIndex

💡 Чтобы сделать маршрут постоянным:

route -p add 0.0.0.0 mask 0.0.0.0 <Gateway-IP> metric 10 if <Interface-Index>

Сервер снова начал видеть внешний мир, DNS заработал, всё ок.

❓Бывало у вас, что после каких-то манипуляций сеть в Windows начинает жить своей жизнью? Как боретесь?

👉 @win_sysadmin

👋 Привет, админы!

Недавно столкнулся с проблемой — один из пользователей жаловался, что «всё долго открывается», особенно сетевые папки. На первый взгляд — обычная история, но решил покопать глубже.

📌 Оказалось, виноват механизм автоматического поиска сетевых принтеров и папок, который Windows выполняет при каждом открытии проводника. На слабых или загруженных машинах это может серьезно замедлить работу.

✅ Быстрое решение — отключить этот механизм через реестр или GPO. Вот способ через PowerShell:

Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" -Name "NoNetCrawling" -Value 1

🔧 Этот параметр отключает автоматическое сканирование сети на предмет расшаренных ресурсов. Пользователь сам откроет то, что нужно — без лишних тормозов. Проверено — сразу стал отзывчивее проводник и пропали лаги при открытии «Сеть».

💬 А вы отключаете сетевой кроллинг в проводнике? Или считаете, что пусть лучше всё видно, хоть и медленно? Делитесь мнением!

👉 @win_sysadmin

👋 Привет, админы!

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

🔥 В таких случаях здорово помогает Get-Process в связке с Get-Counter и Sort-Object — можно быстро определить, кто именно долбит диск:

Get-Process | Sort-Object -Property IOWriteBytes -Descending | Select-Object -First 10 -Property Name, Id, IOWriteBytes

А если хочется ещё точнее — вот пример с использованием счётчиков производительности:

Get-Counter '\Process(*)\IO Write Bytes/sec' | 
Select-Object -ExpandProperty Countersamples | 
Sort-Object CookedValue -Descending | 
Select-Object -First 10

💡 Часто в топе — антивирус, SQL Server, или какой-нибудь рендератор типа ffmpeg.exe. Но однажды у меня неожиданно всплыл spoolsv.exe — оказалось, застрявшая очередь печати на сетевом принтере грузила систему!

💬 А как вы определяете, кто нагружает диск? Есть любимые утилиты или скрипты? Делитесь опытом!

👉 @win_sysadmin

👋 Привет, админы!

Тут на хабре пишут👇

Обновление KB5058379 для Windows 10 22H2 заставляет ПК загружаться в Recovery и требовать ключ BitLocker

В середине мая Microsoft выпустила накопительное обновление безопасности KB5058379 для Windows 10 22H2 и 21H2, включая редакции LTSC/Enterprise, в рамках вторника патчей за май 2025 года. Пользователям и системным администраторам компаний с парком ПК Dell, HP или Lenovo на этих версиях ОС с новым обновлением пришлось столкнуться с перезагрузкой в Recovery и требованием ввести ключ BitLocker. Также у части пользователей начал возникать BSoD после развёртывания KB5058379.

В большинстве случаев проблема касается корпоративных клиентов, кто использует SCCM или WSUS.

Если ПК застрял на экране восстановления Windows или восстановления BitLocker («Введите ключ восстановления, чтобы снова начать») после KB5058379, нужно выполнить следующие действия:

перезагрузить ПК и зайти в BIOS/UEFI;

в настройках зайти на вкладку Security, открыть меню Virtualization или Advanced CPU Settings;

отключить опцию Intel TXT (другие название: Trusted Executio или OS Kernel DMA Support)

опцию VT for Direct I/O (или VT‑d) можно оставить включённой.

сохранить изменения и выйдите из BIOS.

Идея состоит в том, чтобы отключить Intel TXT и позволить KB5058379 завершить установку. Если правильно выполнить эти действия, то далее не будет ошибки с восстановлением BitLocker или BSOD. Примечательно, что в документе техподдержки Microsoft по‑прежнему указано, что компания не знает о каких‑либо новых проблемах с KB5058379.


https://support.microsoft.com/ru-ru/topic/13-%D0%BC%D0%B0%D1%8F-2025-%D0%B3-kb5058379-%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8-%D0%BE%D1%81-19044-5854-%D0%B8-19045-5854-0a30e9ee-5038-45dd-a5d7-70a8813a5e39

https://www.windowslatest.com/2025/05/15/windows-10-kb5058379-locks-pcs-bitlocker-recovery-triggered-on-boot-bsods/

👉 @win_sysadmin

👋 Привет, админы!

Сегодняшний кейс — куда уходит свободное место на диске? Думаешь, что всё под контролем, а потом бац — и диск C: в красной зоне. Особенно часто такое встречал на серверах с включённым журналированием или забытым логированием.

📌 Вот скрипт, который помогает быстро найти топ папок и файлов, пожирающих пространство:

$path = "C:\"
Get-ChildItem -Path $path -Recurse -ErrorAction SilentlyContinue |
    Where-Object { -not $_.PSIsContainer } |
    Sort-Object Length -Descending |
    Select-Object FullName, @{Name="SizeMB";Expression={[math]::round($_.Length / 1MB, 2)}} -First 20

🔥 А если хочешь посмотреть топ папок, используй du из Sysinternals:

.\du.exe -q -l 1 C:\

(если не знаешь — du.exe можно взять отсюда)

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

💬 А как ты мониторишь место на диске? Может, у тебя есть любимый скрипт или тулза, которая всегда под рукой?

👉 @win_sysadmin

👋 Привет, админы!

Знакома ситуация: вроде бы всё обновили, службы перезапустили, а сервер всё равно ведёт себя странно? Часто причина — необходим перезапуск, о котором система молчит.

💡 Чтобы не лазить вручную по реестру, вот скрипт, который проверит, требуется ли перезагрузка:

function Test-PendingReboot {
    $rebootPending = $false

    $paths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending',
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired',
        'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations'
    )

    foreach ($path in $paths) {
        if (Test-Path $path) {
            $rebootPending = $true
            Write-Host "⏳ Pending reboot detected at: $path"
        }
    }

    return $rebootPending
}

# Пример использования:
if (Test-PendingReboot) {
    Write-Host "⚠️ Сервер требует перезагрузки!"
} else {
    Write-Host "✅ Всё чисто — перезагрузка не требуется."
}

Этот скрипт можно легко интегрировать в свои проверки, в том числе в DSC, Zabbix-агенты, или просто в планировщик задач после установки апдейтов.

🛠 Кстати, начиная с Windows Server 2019 можно также использовать Get-WindowsUpdateLog и UpdateCompliance для более глубокой аналитики.

💬 А ты как отслеживаешь pending reboot? Есть любимый способ или используешь сторонние тулзы?

👉 @win_sysadmin

👋 Привет, админы!

Поймал недавно нестандартную проблему на одном из клиентских Windows 11. Пользователь жаловался: не работает печать, а в очереди — вечно зависшие задания. Перезапуск spooler'а не помогал.

Разбор показал — виноват битый драйвер, но перед этим пришлось как следует почистить очередь печати и файлы, чтобы дать системе "вдохнуть". Делюсь скриптом, который меня спас:

🔥 Полная зачистка очереди печати и временных файлов spooler:

Stop-Service -Name spooler -Force
Remove-Item -Path "C:\Windows\System32\spool\PRINTERS\*" -Force
Start-Service -Name spooler

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

💡 А чтобы в следующий раз не искать виновника вручную, добавил логирование проблем с драйверами через Get-EventLog:

Get-EventLog -LogName System -Source "Print" -EntryType Error -Newest 20

Очень удобно — сразу видно, какой драйвер шалит.

💬 А ты как борешься с зависшей печатью? Может, есть свой скрипт или проверенный способ — делись в комментах!

👉 @win_sysadmin

👋 Привет, админы!

Сегодня поймал подозрительную задачу в планировщике Windows — срабатывала каждый час и тянула PowerShell с base64-строкой.
Выглядело безобидно (UpdateTask1), но явно не из дружелюбных...

🔍 Если хочешь быстро проверить, нет ли на твоем сервере вредоносных или странных задач, вот скрипт, который я использую:

Get-ScheduledTask | ForEach-Object {
    $task = $_
    $actions = ($task.Actions | Where-Object { $_.Execute -match "powershell|cmd|wnoscript|cnoscript" })
    if ($actions) {
        [PSCustomObject]@{
            TaskName = $task.TaskName
            Path     = $task.TaskPath
            Action   = $actions.Execute + " " + $actions.Arguments
            UserId   = $task.Principal.UserId
        }
    }
} | Format-Table -AutoSize

💡 Скрипт вытаскивает все задачи, где используется PowerShell, cmd или скриптовые интерпретаторы — часто именно через них атакующие запускают свой код.
Особенно стоит насторожиться, если аргументы содержат -EncodedCommand, iex, или обращения к внешним ресурсам.

📌 Кстати, найденная мной задача маскировалась под системную и запускалась от SYSTEM — проверяй, кому доверена каждая задача.

💬 А ты проверяешь планировщик в своих аудитах? Может, есть свои лайфхаки для поиска шела?

👉 @win_sysadmin