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

Недавно прилетел тикет: "Пользователь не может поменять пароль — ошибка 0x80070056". Если кто не в курсе, это значит "The specified network password is not correct", и возникает она... когда всё вроде бы ОК 🤯

🛠️ В моём случае виновником оказался кэш старого пароля в Credential Manager. Пользователь менял пароль, но RDP-сессия, Outlook и прочее продолжали пытаться авторизоваться по старому — получался конфликт.

📌 Решение:
1. Открыл Credential Manager (Панель управления → Учетные данные).
2. Удалил все записи, связанные с этим аккаунтом.
3. Перезапустил сеанс — пароль сменился без проблем.

💡 Полезная PowerShell-команда, чтобы напомнить пользователям об этом автоматом (например, при смене пароля):

msg * "Если возникли проблемы после смены пароля — проверьте Credential Manager на старые записи!"

Иногда простые вещи — самые коварные. Не забывайте про этот момент, особенно если юзеры работают через RDP или VPN.

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

👉 @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

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

💬 А вы ведёте собственный набор таких команд? Может, пора сделать свой PowerShell toolbox?

👉 @win_sysadmin

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

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

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

$log = "C:\Logs\startup-debug-$(Get-Date -Format 'yyyyMMdd-HHmmss').log"

@"
Start Time: $(Get-Date)
User: $env:USERNAME
Computer: $env:COMPUTERNAME
WorkingDir: $(Get-Location)
ScriptPath: $PSCommandPath
ENV_VARS:
$(Get-ChildItem env: | Out-String)
"@ | Out-File -FilePath $log -Encoding UTF8

🔥 Благодаря этому сразу видно, под кем и откуда запускается задача. Часто проблема оказывается в банальной нехватке прав или в том, что планировщик стартует скрипт из C:\Windows\System32, а не откуда мы ожидали.

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

👉 @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
   

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

💬 А у вас были проблемы из-за времени? Как организуете 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/script указал 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