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

Недавно словил интересную ситуацию: доменный контроллер начал подвисать при логоне пользователей. Логи пустые, нагрузка на 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

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

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

Бывает так, что служба на Windows Server переходит в состояние "Stopping", и ни остановить, ни перезапустить её обычными средствами нельзя. Висит мёртвым грузом, блокируя работу приложения.

🔥 Решение: небольшой скрипт на PowerShell, который убивает процесс, связанный со службой:

$serviceName = "wuauserv"   # сюда вписываем имя службы
$service = Get-WmiObject win32_service -Filter "name='$serviceName'"
Stop-Process -Id $service.ProcessId -Force

После этого службу можно спокойно стартануть:

Start-Service -Name $serviceName

💡Лайфхак: такой скрипт можно положить в .ps1 и запускать от имени администратора, когда что-то "подвисло". Особенно актуально для обновлений и антивирусов, которые любят залипать.

👉 @win_sysadmin

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

Из личного опыта: один сервер Windows Server 2019 стал жутко тормозить, при этом процессор был свободен, а памяти хватало. Логично — лезем в Resource Monitor и видим: диск забит I/O под завязку.

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

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

Эта команда показывает топ процессов по дисковым операциям. У меня оказался какой-то бэкапный агент, который ушёл в бесконечный цикл.

⚡ В таких случаях бывает полезно и вот это:

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

- чтобы понять, кто именно засирает диск записями.

📌 В итоге отключил глючный сервис, нагрузка упала, сервер ожил.

💬 А вы как мониторите дисковую активность? Используете PowerShell, perfmon, сторонние тулзы вроде iometer, Sysinternals Process Explorer?

👉 @win_sysadmin

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

Однажды произошел интересный случай: Windows Server 2019 начал странно грузить диск - процент активности подскакивает до 100%, а скорость чтения/записи при этом смешная. Сначала подумал на «умирающий» HDD, но диск был SSD и в порядке.

🔍 Виновником оказался Superfetch (SysMain) - служба, которая подгружает часто используемые данные в память. На рабочих станциях это иногда ускоряет запуск приложений, но на сервере с ограниченными ресурсами может наоборот создать узкое место.

📌 Быстро проверить, кто именно грузит диск, можно так:

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

А отключить SysMain - вот так:

Stop-Service -Name "SysMain" -Force
Set-Service -Name "SysMain" -StartupType Disabled

После этого нагрузка сразу упала, сервер задышал нормально.

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

💬 А у вас было такое, что служебные процессы Windows больше мешали, чем помогали? Какие отключаете в первую очередь?

👉 @win_sysadmin

Бесплатный урок по Apache Kafka⭐️

Учим работать с реальными исходными данными, а не на теоретических примерах.

✅Расскажем про язык Кафки: топики, партиции, продюсеры-консьюмеры, кластер, ноды. 

✅Рассмотрим: как работают очереди сообщений, сколько должно быть консьюмеров для эффективной вычитки, как повысить надёжность кластера с помощью репликации данных.

✅Покажем, как развернуть кластер Кафки на своём ПК с 3 нодами, schema-registry и авторизацией.

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

Забрать урок👉🏻в боте