Системный Администратор Windows

👋 Привет, админы! Недавно столкнулся с интересным кейсом: один из файловых серверов начал сигнализировать о недостатке свободного пространства. При проверке выяснилось, что причиной стали старые логи IIS и системные файлы, которые копились неделями. Для нас, админов, важно держать «мусор» под контролем, чтобы не проснуться однажды с дискoм, полностью забитым «ненужными» данными. 🔥 В таких случаях мне помогает небольшой PowerShell-скрипт для автоматической очистки логов старше заданного числа дней. Вот что я настроил:

# Путь до папки с логами (пример для IIS)
$LogPath = "C:\inetpub\logs\LogFiles"

# Возраст файлов (в днях), после которого файлы подлежат удалению
$DaysThreshold = 30

# Получаем все файлы в папке и вложенных каталогах старше $DaysThreshold
$OldLogs = Get-ChildItem -Path $LogPath -Recurse -File |
           Where-Object { ($_.LastWriteTime -lt (Get-Date).AddDays(-$DaysThreshold)) }

# Если есть файлы для удаления, выводим их и удаляем
if ($OldLogs) {
    Write-Host "Найдены логи старше $DaysThreshold дней:`n" -ForegroundColor Yellow
    $OldLogs | Select-Object FullName, LastWriteTime | Format-Table -AutoSize

    # Удаляем найденные файлы
    $OldLogs | Remove-Item -Force -Verbose
    Write-Host "`nОчистка завершена." -ForegroundColor Green
} else {
    Write-Host "Файлы старше $DaysThreshold дней не найдены." -ForegroundColor Green
}

Основные моменты: 1. Гибкая настройка пути: в переменной $LogPath можно указать любую директорию – например, логи SQL Server (C:\Program Files\Microsoft SQL Server\MSSQLxx.MSSQLSERVER\MSSQL\Log) или системные временные папки (C:\Windows\Temp). 2. Параметр возраста: переменная $DaysThreshold задаёт, сколько дней «жить» файлам, прежде чем они удалятся. Можно настроить, например, на 7 дней для критических логов или на 90 дней для менее важных. 3. Рекурсивный обход: флаг -Recurse позволяет удалять не только файлы в корне, но и во вложенных папках (удобно, если логи разбиты по датам или подпапкам). 4. Безопасность: перед удалением скрипт выводит список удаляемых файлов. Если сомневаетесь — закомментируйте строку Remove-Item и сначала просто отследите, какие файлы будут выбраны. 💬 Я запланировал выполнение этого скрипта через Task Scheduler каждую неделю в воскресенье в полночь. В результате освободилось несколько десятков гигабайт и администраторы перестали получать тревожные письма о заполненном разделе C:. А как вы справляетесь с накоплением логов на серверах? Может, используете какие-то централизованные решения (SIEM, Splunk, ELK) для ретеншена и ротации? Делитесь своими приёмами в комментариях! 👉 @win_sysadmin

👋 Привет, админы! Если не ошибаюсь, осенью 21 года в одном из наших дата-центров после планового обновления клиентских машин начали массово падать сеансы RDP - пользователи жаловались, что после ввода пароля сессия сразу же разрывается. Оказалось, во время апдейта поставился неполностью совместимый патч безопасности, который конфликтовал с включённым на компьютерах аудиторией учетных политик. 🔥 Чтобы быстро отследить все последние установленные обновления на целевой группе машин и при необходимости откатить проблемный патч, я использовал вот такой PowerShell-скрипт:

# Получаем список компьютеров из текстового файла
$computers = Get-Content -Path "C:\Scripts\computers.txt"

# Словарь для хранения списка установленных обновлений
$updateReport = @()

foreach ($computer in $computers) {
    try {
        # Получаем установленные обновления за последние 7 дней
        $recentUpdates = Get-HotFix -ComputerName $computer |
                         Where-Object { $_.InstalledOn -ge (Get-Date).AddDays(-7) }

        foreach ($upd in $recentUpdates) {
            $updateReport += [PSCustomObject]@{
                Computer   = $computer
                KBArticle   = $upd.HotFixID
                InstalledOn = $upd.InstalledOn
            }
        }
    }
    catch {
        Write-Warning "Не удалось получить обновления с сервера $computer: $_"
    }
}

# Сохраняем отчёт в CSV
$csvPath = "C:\Scripts\RecentUpdatesReport.csv"
$updateReport | Export-Csv -Path $csvPath -NoTypeInformation -Encoding UTF8

Write-Host "Отчет сохранен в $csvPath"

С помощью этого отчёта мы быстро определили, что именно на всех проблемных ПК установился KB5005565. Чтобы откатить его удалённо, использовал команду:

Invoke-Command -ComputerName (Get-Content "C:\Scripts\computers.txt") -ScriptBlock {
    wusa /uninstall /kb:5005565 /quiet /norestart
}

После перезапуска машин RDP-сессии вернулись в норму. Плюс я добавил правило на WSUS, чтобы этот конкретный патч не раздавался снова до выяснения причины конфликта. 👉 @win_sysadmin

👋 Привет, админы! Недавно был случай, один из файловых серверов неожиданно перестал принимать события - логи просто «забились» до предела, из-за чего служба безопасности не могла записывать критичные события входа. Оказалось, что журналы событий выросли до 10 ГБ и система больше не записывала новые записи. 🔥 Чтобы предотвратить подобные ситуации, я собрал небольшой скрипт для автоматического архивации и очистки журналов событий, когда их размер превышает заданный порог. Вот пример, который запустил на сервере:

# Порог в мегабайтах
$logSizeThresholdMB = 1024

# Папка для архивации
$archivePath = "D:\EventLogArchives"
if (-not (Test-Path $archivePath)) {
    New-Item -Path $archivePath -ItemType Directory | Out-Null
}

# Функция для проверки и архивации логов
function Archive-And-Clear-EventLog {
    param (
        [string]$LogName
    )
    # Определяем текущий размер лога
    $logInfo = wevtutil gl $LogName
    $fileSizeLine = ($logInfo | Where-Object { $_ -match "fileSize" })
    $sizeBytes = [int64]($fileSizeLine -replace "[^0-9]", "")
    $sizeMB = [math]::Round($sizeBytes / 1MB, 2)

    if ($sizeMB -ge $logSizeThresholdMB) {
        $timestamp = (Get-Date).ToString("yyyyMMdd_HHmmss")
        $archiveFile = Join-Path $archivePath "$LogName`_$timestamp.evtx"

        # Экспортируем текущий журнал
        wevtutil epl $LogName $archiveFile
        Write-Host "Архивировал лог $LogName (размер $sizeMB MB) в $archiveFile"

        # Очищаем журнал
        wevtutil cl $LogName
        Write-Host "Очищен лог $LogName"
    } else {
        Write-Host "Лог $LogName в пределах нормы: $sizeMB MB"
    }
}

# Получаем все журналы, которые хотим контролировать (пример: System и Security)
$logsToCheck = @("System", "Security")
foreach ($log in $logsToCheck) {
    Archive-And-Clear-EventLog -LogName $log
}

Этот скрипт проверяет размер каждого указанного журнала, экспортирует его в папку архива, если размер больше 1 ГБ, и очищает файл. Я поставил его в Task Scheduler с частотой 1 раз в сутки, чтобы не «догонять» проблему вручную. 👉 @win_sysadmin

👋 Привет, админы! Недавно столкнулся с ситуацией: на одном из серверов системный диск практически «забился» под завязку, а штатные чистилки мусора не помогали - свободного места оставалось критически мало. Оказалось, что куча старых файлов обновлений, временных логов и упаковок пакетов Windows Update съели не меньше 20 ГБ! 🔥 Чтобы оперативно и централизованно освободить место на C:, я использовал PowerShell-скрипт для сброса компонентов Windows Update и удаления временных файлов.

# 1. Остановим службы обновлений
Write-Host "Останавливаю службы Windows Update..." -ForegroundColor Cyan
Stop-Service -Name wuauserv -Force
Stop-Service -Name bits -Force
Stop-Service -Name cryptsvc -Force

# 2. Переименуем папки SoftwareDistribution и Catroot2 (чтобы сбросить кеш)
$sd = "C:\Windows\SoftwareDistribution"
$cr2 = "C:\Windows\System32\catroot2"
$timestamp = Get-Date -Format "yyyyMMdd_HHmmss"
Write-Host "Переименовываю SoftwareDistribution и Catroot2..." -ForegroundColor Cyan
Rename-Item -Path $sd -NewName "SoftwareDistribution_$timestamp" -Force
Rename-Item -Path $cr2 -NewName "catroot2_$timestamp" -Force

# 3. Запустим службы обратно
Write-Host "Запускаю службы Windows Update..." -ForegroundColor Cyan
Start-Service -Name wuauserv
Start-Service -Name bits
Start-Service -Name cryptsvc

# 4. Удаляем временные файлы пользователя и систему temp
Write-Host "Удаляю временные файлы..." -ForegroundColor Cyan
Get-ChildItem "C:\Windows\Temp" -Recurse -Force | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue
Get-ChildItem "$env:TEMP" -Recurse -Force | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue

# 5. Очищаем папку Prefetch (если нужно)
Write-Host "Очищаю Prefetch (опционально)..." -ForegroundColor Cyan
Get-ChildItem "C:\Windows\Prefetch" -Recurse -Force | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue

# 6. Запускаем анализ и дефрагментацию (для HDD/SDD команда отличается)
Write-Host "Запускаю оптимизацию диска (для HDD)..." -ForegroundColor Cyan
Optimize-Volume -DriveLetter C -ReTrim -Verbose

Write-Host "Готово! Освобождено место и сброшен кеш Windows Update." -ForegroundColor Green

🔍 Что делает скрипт: 1. Останавливает службы wuauserv, bits и cryptsvc, чтобы освободить доступ к файлам обновлений. 2. Переименовывает папки SoftwareDistribution и catroot2 - таким образом Windows создаёт новые «чистые» папки при следующем запуске службы обновлений. 3. Перезапускает службы, чтобы система могла продолжить получать обновления. 4. Удаляет старые временные файлы из C:\Windows\Temp и из переменной %TEMP% текущего пользователя. 5. (Опционально) Очищает папку Prefetch - пригодится, если вы хотите сбросить предзагрузку приложений (иногда помогает ускорить старт служб). 6. Запускает командлет Optimize-Volume с параметром –ReTrim (важно для SSD, если нужно, или дефрагментацию для HDD), что в итоге дополнительно освобождает свободное пространство и приводит метаданные диска в порядок. 💡 Лайфхак: - Если вы работаете со множеством серверов, оберните этот скрипт в экспорт модуля или сохраните в виде .ps1, а затем запускайте его через Scheduled Task по расписанию раз в неделю/месяц. - Можно добавить проверку свободного места перед выполнением очистки, чтобы скрипт запускался, только когда доступно меньше, скажем, 10 ГБ:

  $freeGB = [math]::Round((Get-PSDrive -Name C).Free / 1GB, 2)
  if ($freeGB -lt 10) {
      # выполняем очистку
  } else {
      Write-Host "Достаточно места — пропускаю действия."
  }
  

Не забывайте тестировать на тестовых окружениях перед тем, как развертывать на продакшне. 👉 @win_sysadmin

👋 Всем админам добрейшего вечера! Как массово поменять пароли локальных администраторов на паре десятков серверов. Ручками это делать долго да и не очень безопасно. Лучше освободившееся время потрачу с пользой 🍺 Поэтому автоматизируем процесс через PowerShell. Ниже собственно скрипт:

$servers = @("Server01", "Server02", "Server03") # список серверов
$newPass = ConvertTo-SecureString "Новый_Сложный_Пароль!" -AsPlainText -Force

foreach ($srv in $servers) {
    Invoke-Command -ComputerName $srv -ScriptBlock {
        param($pass)
        $user = [ADSI]"WinNT://./Administrator,User"
        $user.SetPassword($pass)
    } -ArgumentList $newPass
}

⚡️ Важно: убедись, что у тебя есть права на все машины и открыт WinRM! Если хочется более гибко, можно расширить скрипт, добавить логирование или рандомизацию паролей. 👉 @win_sysadmin

⚠️Alert: применена скидка 60% Сообщение: Похоже, кто-то обновил прод в пятницу.  Результат: страница упала, цены — тоже. Курсы по DevOps, Kubernetes, SRE и другим направлениям теперь со скидкой 60% Статус: ❗️ DevOps готовится откатывать изменения. ❗️ Скидки могут исчезнуть после отката. Действие: 👉 [Забрать скидку, пока откат не начался] ❗️ Скидки ведут себя нестабильно — могут упасть или подняться в любой момент.

👋 Привет, админы! Пользователи массово жаловались на медленный вход в систему. Крутилось приветствие по 3-5 минут. Оказалось, виновата политика групповых дисков, которая грузилась слишком долго. Решение оказалось простым, нужно быстро найти проблемные политики. Вот удобный скрипт на PowerShell для проверки времени обработки GPO при входе пользователя:

Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
Where-Object { $_.Id -eq 4016 } |
Select-Object TimeCreated, @{n='Время загрузки GPO (сек)';e={$_.Properties[0].Value}}, @{n='Название GPO';e={$_.Properties[1].Value}} |
Sort-Object 'Время загрузки GPO (сек)' -Descending | Select-Object -First 10

Этот скрипт покажет 10 самых «тяжёлых» групповых политик по времени загрузки. В моём случае лидером стала политика с забытым сетевым диском на уже не существующий файловый сервер. 👉 @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

👋 Привет, админы! Куда уходит свободное место на диске? Думаешь, что всё под контролем, а потом бац - и диск 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

👋 Привет, админы! Недавно столкнулся с проблемой - один из пользователей жаловался, что «всё долго открывается», особенно сетевые папки. На первый взгляд - обычная история, но решил покопать глубже. 📌 Оказалось, виноват механизм автоматического поиска сетевых принтеров и папок, который Windows выполняет при каждом открытии проводника. На слабых или загруженных машинах это может серьезно замедлить работу. ✅ Быстрое решение - отключить этот механизм через реестр или GPO. Вот способ через PowerShell:

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

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

Как переехать с Prometheus на VictoriaMetrics и для чего? VictoriaMetrics снижает стоимость хранения, требует меньше ресурсов, легко масштабируется и совместима с экосистемой Prometheus. Но с VictoriaMetrics нужно уметь работать!  На видеокурсе от Слёрма вы за 3 часа сможете: 💡 научиться быстро и без боли разворачивать VictoriaMetrics; 💡 освоить 3 способа переезда с Prometheus; 💡 получите готовый чек-лист для миграции, чтобы избежать 99% ошибок новичков; 💡 аргументированно доказать тимлиду или CTO, что переход на VictoriaMetrics сэкономит компании много красивых денег! За 1 день освоить востребованный инструмент или продолжать маяться с Prometheus? Выбор за вами. Все подробности ➡️ по ссылке.

👋 Привет, админы! Сегодня расскажу про один недокументированный нюанс с задачами в Планировщике Windows, с которым недавно столкнулся сам. Был у меня скрипт, который по расписанию должен запускаться от имени системной учетной записи (SYSTEM). Всё настроено правильно, вручную запускается - работает. Но вот по расписанию не срабатывает. Без ошибок, без логов, просто тишина. 🤔 🔍 После копания выяснилось: если задача запускается от SYSTEM, но в свойствах включена опция "Запускать только при входе пользователя", - она НЕ выполнится, потому что SYSTEM не входит в систему в классическом понимании. 💡 Решение: 1. Зайти в свойства задачи. 2. Переключить опцию на: "Выполнять вне зависимости от входа пользователя". 3. Обязательно включить галку "Не сохранять пароль", если используете обычную учетку (для SYSTEM это не критично). 📌 Ну и по возможности включайте логирование в задаче - пусть пишет вывод скрипта в файл, так проще отлавливать подобные "невидимые" фейлы. 👉 @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. 👉 @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% случаев проблема именно там. 👉 @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-адрес источника. Очень удобно запускать на сервере и быстро проверять, кто заходил и когда. Можно адаптировать для логгера или отправки уведомлений. 👉 @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/script указал powershell.exe, а в аргументах: -ExecutionPolicy Bypass -File \\ваш-сервер\netlogon\clean_temp.ps1 Важно: – Скрипт не трогает свежие файлы (новее 7 дней) – Работает бесшумно, ничего не спрашивает – Можно дополнительно чистить C:\Windows\Temp, если уверены Вывод: Не запускайте такую штуку в logon-скриптах - это затормозит вход в систему. Лучше использовать планировщик задач. И, конечно, тестируйте сначала на паре машин — на всякий случай. 👉 @win_sysadmin

👋 Привет, админы! Сегодня расскажу про один кейс, который недавно словил на одном из файловых серверов. Пользователи начали жаловаться, что не могут открыть файлы по 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
   

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

👋 Доброго раннего утра, админы! Как срочно проверить, кто и когда перезагружал сервер. Вроде бы задача простая, но в спешке иногда забываешь точные команды. Делюсь, чтобы не искать в следующий раз: 🕵️‍♂️ Ловим события перезагрузки через журнал:

Get-EventLog -LogName System -Source User32 | Where-Object { $_.EventID -eq 1074 } | Select TimeGenerated, Message | Sort-Object TimeGenerated -Descending

Этот запрос покажет, кто инициировал перезагрузку, с какой причиной и когда это было. Очень полезно при разборе неожиданных рестартов или плановых работ, которые никто "не помнит". ✅ Дополнительно можно глянуть системные события ID 6006 (нормальное выключение) и 6005 (загрузка журнала, т.е. запуск системы):

Get-EventLog -LogName System | Where-Object { $_.EventID -eq 6006 -or $_.EventID -eq 6005 } | Select TimeGenerated, EventID | Sort-Object TimeGenerated -Descending

🔥 Удобно добавлять эти команды в свой набор “быстрых админских команд”. 👉 @win_sysadmin

👋 Доброй субботы, админы! На днях столкнулся с интересной ситуацией: служба Windows Update на одном из серверов Windows Server 2019 просто отказалась стартовать. Перезапуск, reset компонентов — ничего не помогло. Оказалось, что виноват битый файл базы данных обновлений. Решение оказалось простым, но мало кто его делает вручную: 🔥 Вот PowerShell-скрипт, который полностью сбрасывает Windows Update, включая очистку базы данных:

Stop-Service -Name wuauserv -Force
Stop-Service -Name bits -Force
Remove-Item -Path "C:\Windows\SoftwareDistribution" -Recurse -Force
Start-Service -Name wuauserv
Start-Service -Name bits

После этого сервер спокойно начал тянуть апдейты. Главное — не забудьте перезапустить сервисы, а лучше сразу проверить доступность обновлений:

Get-WindowsUpdate

(если стоит PSWindowsUpdate модуль) 💡Если хотите автоматизировать это на нескольких машинах — добавьте Invoke-Command и в путь! 👉 @win_sysadmin

👋 Привет, админы! Если вы уже используете Wazuh (open-source SIEM), то грех не настроить сбор событий безопасности с Windows, особенно для анализа логинов и брутфорса по RDP. Вот как это делается 👇 🛠️ Установка Wazuh Agent на Windows 1. Скачиваем агент отсюда: https://wazuh.com/ 2. Устанавливаем с указанием менеджера (сервер Wazuh):

msiexec /i "wazuh-agent-4.x.x.msi" /qn WAZUH_MANAGER="10.0.0.1" WAZUH_REGISTRATION_SERVER="10.0.0.1" WAZUH_AGENT_NAME="srv-win01"

3. После установки — правим C:\Program Files (x86)\ossec-agent\ossec.conf (если надо вручную задать имя, группы и т.п.) 4. Перезапускаем агент:

net stop wazuh-agent
net start wazuh-agent

📋 Что собирает агент? По умолчанию: - События из Security, System, Application - Входы в систему (4624, 4625, 4778, 4779) - Изменения в учётках, политиках, реестре - Информация об установке/удалении софта 🎯 Всё это попадает в дашборд Wazuh и может быть обработано правилами: алерты, уведомления, триггеры. 🔥 Пример алерта в Wazuh при брутфорсе по RDP:

{
  "rule": {
    "id": "18107",
    "level": 10,
    "description": "Windows RDP brute-force attempt detected",
    "group": "windows, authentication_failed, brute_force"
  },
  "srcip": "192.168.1.200",
  "user": "admin",
  "location": "Security",
  "full_log": "Logon failure: Type 10 (RemoteInteractive)"
}

📌 Это можно отправить на почту, в Telegram, или автоматизировать блокировку IP (например, через Active Responses). 💬 А вы уже пробовали Wazuh или у вас другая SIEM-система? Сравнивали с Graylog, Splunk, Sentinel? 👉 @win_sysadmin