Системный Администратор Windows – Telegram
Системный Администратор Windows
3.12K subscribers
15 photos
2 videos
24 links
🖥️ Windows для системных администраторов: управление, оптимизация, безопасность. Полезные советы, лайфхаки, PowerShell-скрипты, автоматизация и практические решения для работы с серверами и рабочими станциями.

Авторский канал.
Download Telegram
📕 Контейнеризация в Windows Server для системных администраторов, инженеров технической поддержки и начинающих IT-специалистов.

На открытом уроке 22 октября в 20:00 мск мы разберем как использовать контейнеры в Windows Server.

📗 На вебинаре вы:
1. Узнаете, как использовать контейнеризацию для повышения гибкости и управляемости серверной инфраструктуры.
2. Освоите базовые команды и подходы к управлению контейнерами.

📘 В результате на практике развернете свой первый контейнер с помощью Docker и поймете принципы работы контейнеров в Windows Server.

👉 Регистрация и подробности о курсе Администратор Windows: https://vk.cc/cQwN9r

Все участники открытого урока получат скидку на курс "Администратор Windows"

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
4
👋 Всем админам доброго раннего утра!

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

🎯 Включаем аудит входа и сетевых логинов:


AuditPol /set /subcategory:"Logon" /success:enable /failure:enable
AuditPol /set /subcategory:"Logoff" /success:enable
AuditPol /set /subcategory:"Special Logon" /success:enable
AuditPol /set /subcategory:"Logon with explicit credentials" /success:enable /failure:enable


📝 После этого в логе Security начнут появляться события:
- 4624 - Успешный вход (в том числе по RDP - Logon Type 10)
- 4625 - Неудачный вход (ошибка пароля, нет такой учётки и т.п.)
- 4634 - Выход из системы
- 4778 и 4779 - Подключение и отключение от RDP-сессии

📌 Также полезно включить аудит групповой политики:


AuditPol /set /subcategory:"Other Logon/Logoff Events" /success:enable /failure:enable


👉 @win_sysadmin
👍171
👋 Привет, админы!

Если вы уже используете 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,
"denoscription": "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
👍95
👋 Доброй субботы, админы!

На днях столкнулся с интересной ситуацией: служба 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
👍15
👋 Доброго раннего утра, админы!

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

🕵️‍♂️ Ловим события перезагрузки через журнал:


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
👍11
👋 Привет, админы!

Сегодня расскажу про один кейс, который недавно словил на одном из файловых серверов. Пользователи начали жаловаться, что не могут открыть файлы по 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
👍15🤯2👎1
Как я автоматизировал очистку 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
🔥17👍7🤔21
👋 Привет, админы!

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

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

Сегодня расскажу про один неожиданный баг, с которым столкнулся на 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
👍9🔥41
👋 Привет, админы!

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

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

💡 Решение:

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

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

👉 @win_sysadmin
👍131
Как переехать с Prometheus на VictoriaMetrics и для чего?

VictoriaMetrics снижает стоимость хранения, требует меньше ресурсов, легко масштабируется и совместима с экосистемой Prometheus. Но с VictoriaMetrics нужно уметь работать! 

На видеокурсе от Слёрма вы за 3 часа сможете:

💡 научиться быстро и без боли разворачивать VictoriaMetrics;
💡 освоить 3 способа переезда с Prometheus;
💡 получите готовый чек-лист для миграции, чтобы избежать 99% ошибок новичков;
💡 аргументированно доказать тимлиду или CTO, что переход на VictoriaMetrics сэкономит компании много красивых денег!

За 1 день освоить востребованный инструмент или продолжать маяться с Prometheus? Выбор за вами.

Все подробности ➡️ по ссылке.
1
👋 Привет, админы!

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

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

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


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


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

👉 @win_sysadmin
👍19🔥8
👋 Привет, админы!

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

Была давече нестандартная проблема на одном из клиентских 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
👍15
👋 Привет, админы!

Пользователи массово жаловались на медленный вход в систему. Крутилось приветствие по 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
👍4🔥2👎1👏1
👋 Всем админам добрейшего вечера!

Как массово поменять пароли локальных администраторов на паре десятков серверов.

Ручками это делать долго да и не очень безопасно. Лучше освободившееся время потрачу с пользой 🍺 Поэтому автоматизируем процесс через 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
👍132
👋 Привет, админы!

Недавно столкнулся с ситуацией: на одном из серверов системный диск практически «забился» под завязку, а штатные чистилки мусора не помогали - свободного места оставалось критически мало. Оказалось, что куча старых файлов обновлений, временных логов и упаковок пакетов 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
👍162🫡1
👋 Привет, админы!

Недавно был случай, один из файловых серверов неожиданно перестал принимать события - логи просто «забились» до предела, из-за чего служба безопасности не могла записывать критичные события входа. Оказалось, что журналы событий выросли до 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
👍8👏1
👋 Привет, админы!

Если не ошибаюсь, осенью 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
13👍9