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

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

🕵️‍♂️ В итоге нашёл внедрение в процесс через WMI. Да-да, старый добрый WMI стал каналом для персистентности малвари. Чтобы выявить такие вещи, добавил себе в регулярный аудит вот такую проверку:

Get-WmiObject -Namespace "root\subscription" -Class __FilterToConsumerBinding |
Select-Object -Property Filter, Consumer

А дальше уже идёт разбор через:

Get-WmiObject -Namespace "root\subscription" -Class __EventFilter
Get-WmiObject -Namespace "root\subscription" -Class CommandLineEventConsumer

⚠️ Если видите странные команды, непонятные пути, особенно с PowerShell или cmd.exe — повод для расследования.

Ну и напоследок

- Регулярно просматривайте WMI-события.
- Включите логирование WMI через Event ID 5861/5860 (Microsoft-Windows-WMI-Activity/Operational).
- Используйте Sysmon — он хорошо ловит подобные фокусы (Event ID 1 + родительские процессы).

💬 А вы мониторите WMI в своих инфраструктурах? Есть ли какие-то интересные кейсы? Поделитесь опытом!

👉 @win_sysadmin

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

Бывает, нужно быстро понять, какие задачи по расписанию крутятся на сервере. Особенно когда сервер ведёт себя странно, а в логах — тишина. У меня был случай, когда скрипт сливал логи на сторону, а запускался через Task Scheduler под безобидным именем UpdateCheck.

🔥 Вот командлет, который мне помог всё быстро найти:

Get-ScheduledTask | Where-Object {$_.TaskPath -notlike '\Microsoft*'} |
Select-Object TaskName, TaskPath, State

А если хотите подробности (что запускается и от какого имени), то:

Get-ScheduledTask | ForEach-Object {
    $info = $_
    Get-ScheduledTaskInfo -TaskName $info.TaskName -TaskPath $info.TaskPath | Select-Object @{Name='Name';Expression={$info.TaskName}}, @{Name='User';Expression={$info.Principal.UserId}}, @{Name='LastRunTime';Expression={$_.LastRunTime}}, @{Name='NextRunTime';Expression={$_.NextRunTime}}, @{Name='Status';Expression={$_.LastTaskResult}}
}

📌 Советую раз в месяц гонять такой скрипт по всем серверам. Лучше найти лишнее самому, чем ждать сюрпризов от пользователей (или вредоносов).

💬 А вы как мониторите задания планировщика? Есть ли скрипты или автоматизация для этого?

👉 @win_sysadmin

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

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

💥 А виноват оказался вот такой зверь:
Ошибка 0x8007000d: Data is invalid при выполнении gpupdate /force.

Что помогло:

1. Проверка журналов через Event Viewer:
Applications and Services Logs -> Microsoft -> Windows -> GroupPolicy -> Operational
Там вылезло: "The processing of Group Policy failed. Data is invalid."

2. Удаление сломанных GPO-кэшей на клиенте:

Remove-Item -Path "C:\ProgramData\Microsoft\Group Policy\History\*" -Recurse -Force
gpupdate /force

3. Также проверил, не повреждён ли Registry.pol:

del /f /q "%SystemRoot%\System32\GroupPolicy\Machine\Registry.pol"

(после этого gpupdate сам пересоздаёт его по актуальным политикам)

✅ После этих действий GPO стали применяться нормально.

📌 На всякий случай теперь мониторю и кэш, и наличие ошибок 7016 / 7017 в журнале GroupPolicy.

💬 А у вас были кейсы с внезапной порчей групповых политик? Чем лечили?

👉 @win_sysadmin

🎉Коллеги, всех причастных с праздником!!!

Желаю, чтобы пользователи сами читали инструкции… хотя бы иногда.»

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

👉 @win_sysadmin

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

На днях словил интересный кейс: Windows Server 2019 внезапно стал жутко медленным после установки обновлений. Диспетчер задач показывал — процессор почти не загружен, памяти хватает, но диски в 100% активности.

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

Stop-Service -Name "WSearch"
Set-Service -Name "WSearch" -StartupType Disabled

А чтобы не остаться без поиска навсегда, вынес отдельный плановый rebuild индекса на ночь (когда сервер не под нагрузкой).

💡 Если вы видите непонятные пиковые нагрузки на диск — первым делом смотрите Get-Process с сортировкой по IO.

Get-Process | Sort-Object -Property IOReadBytes -Descending | Select-Object -First 10

Очень наглядно показывает, кто активно долбит диск.

А как вы решаете проблему индексации? Полностью отключаете Search или настраиваете под себя?

👉 @win_sysadmin

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

Недавно словил интересную ситуацию: доменный контроллер начал подвисать при логоне пользователей. Логи пустые, нагрузка на CPU и RAM в норме. 🤔 Виновник нашёлся не сразу — забитый журнал безопасности (Security Log)!

Когда журнал переполнен и стоит политика “Do not overwrite events”, новые события просто не пишутся, и AD начинает чудить.

📌 Быстро проверить состояние журнала можно так:

Get-WinEvent -ListLog Security | Select-Object LogName, RecordCount, MaximumSizeInBytes, IsLogFull

А чтобы очистить журнал без захода в Event Viewer:

wevtutil cl Security

Ну и чтобы не ловить такие сюрпризы — ставьте автоматическую очистку или увеличьте размер лога:

wevtutil sl Security /ms:524288000

(пример — 500 МБ).

💬 Было ли у вас, что из-за логов система начинала вести себя странно? И какой размер логов держите на контроллерах?

👉 @win_sysadmin

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

Недавно словил интересный кейс: один сервер на Windows Server 2019 внезапно перестал ставить обновления. Центр обновлений ругался на «поврежденные компоненты», но sfc /scannow показывал, что всё ок.

Тут меня выручила DISM — старый добрый инструмент для починки образа системы. Ниже рабочая связка команд:

DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth

⚡ Что делают эти команды:

- CheckHealth — быстро проверяет, есть ли повреждения.
- ScanHealth — делает глубокую диагностику (долго, но надёжно).
- RestoreHealth — чинит поврежденные компоненты через Центр обновлений или указанный источник.

В моем случае именно RestoreHealth вылечил систему, и обновления пошли как по маслу.

💡Если сервер без интернета, можно указать свой ISO-образ Windows:

DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim /LimitAccess

А вы как чините такие баги? DISM, Repair-Install или сразу в продакшн с головой и reinstall? 😄

👉 @win_sysadmin

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

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

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

"The service did not start due to a logon failure"

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

🔧 Чтобы быстро проверить все службы, запускаемые не от LocalSystem, я накатил простой PowerShell-скрипт:

Get-WmiObject Win32_Service |
Where-Object { $_.StartName -notmatch "LocalSystem|LocalService|NetworkService" } |
Select-Object Name, DisplayName, StartName, State

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

sc.exe config "ServiceName" obj= "DOMAIN\User" password= "NewPassword"

После обновления не забудьте перезапустить сервис:

Restart-Service -Name "ServiceName"

⚡ В итоге за 10 минут нашли и починили всё, без долгого копания в GUI.

💬 А вы проверяете периодически пароли сервисных учёток? Есть ли у вас автоматизация для таких случаев?

👉 @win_sysadmin

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

Раз уж тема зашла, делюсь готовым скриптом для массового обновления паролей сервисных учёток. Иногда после смены пароля учётки приходится руками лазить по десяткам серверов и обновлять службы — это ад. Решается всё PowerShell’ем.

Вот скрипт:

# Задаем данные
# автор: https://t.iss.one/win_sysadmin
$ServiceAccount = "DOMAIN\ServiceUser"
$NewPassword = "NewSecurePassword123!"
$Servers = @("Server1","Server2","Server3")  # список серверов

foreach ($Server in $Servers) {
    Write-Host "Обновляю службы на $Server..." -ForegroundColor Cyan
    $services = Get-WmiObject Win32_Service -ComputerName $Server | Where-Object { $_.StartName -eq $ServiceAccount }
    foreach ($svc in $services) {
        Write-Host "  -> Обновляем $($svc.Name) ($($svc.DisplayName))" -ForegroundColor Yellow
        $result = sc.exe \\$Server config $($svc.Name) obj= $ServiceAccount password= $NewPassword
        if ($result -like "*[SC] ChangeServiceConfig SUCCESS*") {
            Restart-Service -Name $svc.Name -ComputerName $Server -Force
            Write-Host "     Перезапущено." -ForegroundColor Green
        } else {
            Write-Host "     Ошибка при обновлении!" -ForegroundColor Red
        }
    }
}

Работа скрипта:

- Берёт список серверов.
- Находит службы, которые работают под указанной учёткой.
- Меняет пароль и сразу перезапускает сервис.

Можно легко адаптировать под CSV, чтобы брать серверы и учётки из файла.

👉 @win_sysadmin

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

Недавно поймал интересный кейс: один из серверов на Windows Server 2019 неожиданно перестал обновляться. Центр обновлений крутился без конца, а в WindowsUpdate.log — стандартный "ничего полезного".

Оказалось, что проблема была в битом кэше обновлений. Решение оказалось простым, но спасло несколько часов:

net stop wuauserv
net stop bits
Remove-Item -Recurse -Force C:\Windows\SoftwareDistribution\*
net start bits
net start wuauserv

После этого сервер спокойно подтянул все обновления.

👉 Маленький лайфхак: если часто сталкиваетесь с зависаниями обновлений, автоматизируйте этот процесс. Например:

$services = "wuauserv","bits"
Stop-Service $services -Force
Remove-Item -Recurse -Force C:\Windows\SoftwareDistribution\*
Start-Service $services
Write-Host "Кэш обновлений очищен!"

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

💬 А вы как решаете проблемы с зависшими обновлениями? Ручками или автоматизацией? Может, используете WSUS или сторонние решения?

👉 @win_sysadmin

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

Недавно столкнулся с ситуацией: на одном из серверов неожиданно пропал доступ к шаре. Казалось бы — стандартная история, но проблема оказалась глубже: сломалась служба LanmanServer (серверная служба, отвечающая за SMB).

Чтобы не лазить каждый раз руками в services.msc, сделал себе маленький скрипт для быстрой проверки и перезапуска:

$service = Get-Service -Name "LanmanServer"
if ($service.Status -ne "Running") {
    Write-Host "Служба Server не запущена. Пробую запустить..."
    Start-Service -Name "LanmanServer"
    Start-Sleep -Seconds 3
    Get-Service -Name "LanmanServer"
} else {
    Write-Host "Служба Server работает нормально."
}

Теперь запускаю его при малейших подозрениях на проблемы с доступом к шарам. Удобно, особенно если комбинировать с уведомлением (например, через Telegram-бота).

💡 Кстати, иногда помогает ещё и перерегистрация библиотек SMB:

regsvr32 srvsvc.dll

А вы мониторите состояние SMB-службы? Может, кто-то автоматизировал перезапуск через Task Scheduler при падении? Делитесь кейсами!

👉 @win_sysadmin

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

Пользователи жаловались на долгий логон на RDS-сервер. Вроде и ресурсов хватает, и сеть нормальная — а сессия грузится по минуте.

Покопался в логах и наткнулся на то, что отрабатывает куча лишних GPO, в том числе старые скрипты входа, которые уже давно никому не нужны.

Быстро проверить, какие политики реально применяются, помогла вот такая команда:

gpresult /h C:\Temp\GPO_Report.html

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

А еще можно через PowerShell собрать сводку по GPO и времени логина:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-GroupPolicy/Operational';ID=5312} |
Select-Object TimeCreated, Message |
Sort-Object TimeCreated -Descending |
Select-Object -First 20

Так я нашел пару древних скриптов, которые тормозили загрузку профиля. Удалил — и логон снова за 10 секунд! 🚀

💬 А у вас часто встречаются такие "призраки прошлого" в GPO? Как вы отслеживаете, что реально используется, а что пора выкинуть?

👉 @win_sysadmin

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

Ко вчерашнему посту про долгий логин, - топ-10 команд для быстрой диагностики проблем логина на Windows-серверах и рабочих станциях.

Если пользователи жалуются на долгий вход или подвисания - вот с чего начинаю копать:


1. Какие политики реально применяются:

gpresult /h C:\Temp\GPO_Report.html

Отчет в HTML сразу покажет все GPO и их статус.

2. Время применения групповых политик:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-GroupPolicy/Operational';ID=5312} |
Select-Object TimeCreated, Message

3. Анализ процессов при логоне:

Get-Process | Sort-Object StartTime -Descending | Select-Object -First 20

Можно понять, что запускается последним и тормозит старт.

4. Диагностика профиля пользователя:

Get-WmiObject Win32_UserProfile | Select LocalPath, LastUseTime, Special

Выявляем битые или старые профили.

5. События медленного входа (Winlogon):

Get-WinEvent -LogName 'Microsoft-Windows-Winlogon/Operational' | 
Select TimeCreated, Id, Message -First 20

6. Проверка сетевых задержек (DC):

nltest /dsgetdc:DOMAINNAME

Быстро видим, к какому контроллеру цепляется клиент.

7. Тест производительности сети:

Test-NetConnection DC_NAME -Port 389

Проверка доступности LDAP-порта.

8. Проверка кешированных профилей:

dir "C:\Users" | Sort-Object LastWriteTime

9. Время выполнения скриптов входа:

Get-WinEvent -LogName 'Microsoft-Windows-Shell-Core/Operational' | 
? {$_.Message -like "*Logon Script*"} | Select TimeCreated, Message

10. Чтение журналов User Profile Service:

Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' |
Select TimeCreated, Id, Message -First 20

🔥 Эти команды помогают понять: проблема в политике, профиле, сети или скриптах.

💬 А вы как диагностируете долгий логон? Может, у кого-то есть свои must-have команды? Давайте соберем подборку!

👉 @win_sysadmin

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

На днях попался мне интересный случай: один сервер Windows Server 2019 начал жаловаться пользователям на «медленный отклик» при входе в систему. Логи чистые, CPU и RAM в норме. Но вот вход в RDP занимал секунд 30–40.

Оказалось, что виноват переизбыточный автозапуск — в профилях пользователей накопилось куча мусора: OneDrive, Teams, Zoom и ещё парочка «добрых» помощников стартовали при каждом логоне.

📌 Вот как я быстро вычистил это через PowerShell:

Get-CimInstance Win32_StartupCommand |
Select-Object Name, Command, Location, User |
Sort-Object Name

Эта команда покажет всё, что стартует при входе, включая системные и пользовательские записи.
Дальше можно удалить ненужное:

Get-CimInstance Win32_StartupCommand | Where-Object {$_.Name -like "*Teams*"} | Remove-CimInstance

После чистки вход в систему стал занимать 8–10 секунд.
Так что совет — периодически проверяйте автозапуск, особенно на терминальных серверах.

💬 А вы чистите автозагрузку централизованно через GPO или вручную на серверах?

👉 @win_sysadmin

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

На прошлой неделе словил интересную проблему на одном из тестовых серверов — периодически пропадала связь с определёнными узлами, но пинг и RDP в это время работали. Сначала подумал на фаервол или кривые ACL, но оказалось, что дело в DNS-кэше Windows.

Иногда DNS-клиент кеширует устаревшие записи, и мы получаем «битые» IP-адреса. Решается это быстро:

🔥 Сбросить DNS-кэш:

Clear-DnsClientCache

🔥 Посмотреть, что сейчас в кеше:

Get-DnsClientCache | Sort-Object -Property RecordName

🔥 Полный перезапуск сервиса DNS-клиента:

Restart-Service -Name "Dnscache"

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

💬 А вы чаще чистите DNS-кэш вручную или автоматизируете это через GPO/скрипты?

👉 @win_sysadmin

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

Сегодня словил забавный (но потенциально опасный) момент: после обновления Windows Server 2022 один из сервисов перестал стартовать при загрузке, хотя в Services.msc он стоит на Automatic.

🔍 Оказалось, что проблема в том, что Windows теперь иногда «умно» откладывает запуск сервисов, помеченных как Automatic (Delayed Start), особенно если система решает, что «надо разгрузить старт».

💡 Решение нашлось простое: проверяем и меняем тип запуска на обычный Automatic через PowerShell:

Set-Service -Name "Имя_сервиса" -StartupType Automatic

А если надо массово проверить и поправить сразу несколько сервисов, которые почему-то стоят на Delayed Start:

Get-Service | Where-Object { $_.StartType -eq 'AutomaticDelayedStart' } |
ForEach-Object { Set-Service -Name $_.Name -StartupType Automatic }

После перезагрузки — всё взлетело как надо 🚀.

💬 А вы как относитесь к Delayed Start? Используете для оптимизации загрузки или всегда ставите чистый Automatic?

👉 @win_sysadmin

Используете VPN? Или только планируете внедрять его в корпоративную сеть?
Узнайте, как избежать ошибок при выборе типа VPN для разных задач на вебинаре OTUS 13 августа в 19:00!


❓Как выбрать правильный тип VPN? Поговорим о том, какой сервис нужен для разных задач: офис-офис, облако, удалённые сотрудники
❓Основы IPSec: почему этот фреймворк остаётся одним из самых надежных для построения защищённых VPN-соединений, несмотря на свою сложность
❓Типы VPN и их сравнение: что выбрать для своей инфраструктуры? Почему не все решения одинаково полезны?

Спикер: Николай Колесов — Эксперт ТАС вендора по решениям routing&switching и data center, с опытом работы в самых передовых решениях от Cisco, Juniper и Huawei.

Скидка 7% на любой курс OTUS и подарки для тех, кто примет участие в вебинаре.

Не упусти шанс! Присоединяйся к вебинару, чтобы быть уверенным в защите своей корпоративной сети и не допустить ошибок, которые могут дорого стоить бизнесу!
📝 Записывайтесь на вебинар: https://tglink.io/b6f1c9dda02a

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963. erid: 2W5zFGbpZMa

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

Был случай, на одном Windows Server начали рандомно падать службы, но без явных ошибок в Event Viewer. Логика подсказывала, что дело в правах или зависших сессиях, и, как оказалось, виновником была учетная запись сервиса с истекшим паролем.

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

Get-WmiObject Win32_Service |
Where-Object { $_.StartName -notmatch "LocalSystem|LocalService|NetworkService" } |
Select-Object Name, StartName, State

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

📌 Дополнительно советую настроить напоминание, чтобы раз в квартал проверять пароли сервисных аккаунтов — меньше будет «сюрпризов» в выходные.

💬 А у вас была ситуация, когда сервисы падали из-за паролей? Как автоматизируете их ротацию?

👉 @win_sysadmin

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

Был случай - Windows Server перестал пускать пользователей по RDP. Ошибка в логах: CredSSP encryption oracle remediation. Классика жанра после свежих обновлений.

💡 Решение оказалось простым: нужно на время ослабить политику проверки CredSSP, чтобы пустить людей, а потом уже обновить клиента.

Сделал так через PowerShell:

Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters' `
-Name AllowEncryptionOracle -Value 2 -Type DWord

Значения параметра:

* 0 - запрет небезопасных подключений
* 1 - только с предупреждением
* 2 - разрешить подключение (временно!)

После правки - RDP снова живой. Но важно потом вернуть настройки и обновить все клиенты, иначе это дыра в безопасности.

💬 А вы сталкивались с этой ошибкой?

👉 @win_sysadmin

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

На днях словил кейс: один Windows Server после перезагрузки не поднимал часть сервисов. Лезу в Services.msc — половина служб в состоянии "Starting...", висят и не доходят до Running. Пользователи, конечно, в панике 🙃

📌 Оказалось, что проблема была в том, что несколько зависимых служб стартовали в неправильном порядке. В логах — ошибка 7000/7001 (Service Control Manager).

🔥 Быстро проверить состояние всех служб удобно через PowerShell:

Get-Service | Where-Object {$_.Status -eq 'Stopped' -and $_.StartType -eq 'Automatic'} | Select-Object DisplayName,Name

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

👉 Если надо принудительно запустить такие службы:

Get-Service | Where-Object {$_.Status -eq 'Stopped' -and $_.StartType -eq 'Automatic'} | Start-Service

После прогона сервак ожил, все сервисы поднялись, а пользователи снова счастливы 😊

💡 Лайфхак: если у вас такое повторяется часто — настройте delayed start для "тяжелых" сервисов или проверьте зависимые службы. Это реально экономит нервы.

А у вас бывало, что после перезагрузки сервер "не докручивал" нужные службы? Чем лечили — скриптами или правилом в GPO?

👉 @win_sysadmin

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

Сегодня вспомнил один кейс. На сервере перестали запускаться службы, завязанные на SQL Server, хотя база сама работала.

Оказалось, что одна зависимая служба стартует медленнее обычного, и Windows считает её «неответившей». В итоге цепочка ломается, и сервисы так и остаются в статусе Starting....

🛠 Решение оказалось довольно простым — увеличил таймаут загрузки сервисов. Делается это через реестр:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control" -Name "ServicesPipeTimeout" -Value 60000

Здесь значение указывается в миллисекундах (по умолчанию 30 000). Я поставил 60 секунд, и после перезагрузки службы стали подниматься корректно.

🔥 Лайфхак: перед тем как править реестр, всегда проверяйте, нет ли проблем с производительностью или блокировками в самой системе. Увеличение таймаута — это костыль, но иногда он реально спасает.

👉 @win_sysadmin