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

🔥 Открытый урок «GitLab CI + Ansible: автоматизация инфраструктуры без боли». 🗓 27 августа в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «CI/CD на основе GitLab». 🎯 На вебинаре разберем: ✔️ Как настроить GitLab CI для работы с Ansible ✔️ Организация пайплайна для автоматического запуска Ansible-плейбуков ✔️ Как тестировать и проверять изменения в Ansible до деплоя ✔️ Использование GitLab CI как среды для обучения и отладки Ansible 👥 Кому будет интересно: - DevOps-инженерам, которые осваивают или уже используют GitLab CI и Ansible, и хотят связать их в единый, автоматизированный процесс - Начинающим специалистам, изучающим инфраструктурный код и автоматизацию - Техническим архитекторам, заинтересованным в построении масштабируемых и управляемых CI/CD процессов с Ansible 🎯 Что вы получите: - Практическое понимание интеграции Ansible с GitLab CI - Готовые идеи и примеры для запуска и тестирования Ansible-плейбуков - Уверенность в использовании CI/CD пайплайнов для инфраструктурных задач и конфигурационного менеджмента 🔗 Ссылка на регистрацию: https://vk.cc/cOK1WM Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

👋 Привет, админы! Сегодня вспомнил один кейс. На сервере перестали запускаться службы, завязанные на SQL Server, хотя база сама работала. Оказалось, что одна зависимая служба стартует медленнее обычного, и Windows считает её «неответившей». В итоге цепочка ломается, и сервисы так и остаются в статусе Starting.... 🛠 Решение оказалось довольно простым — увеличил таймаут загрузки сервисов. Делается это через реестр:

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

Здесь значение указывается в миллисекундах (по умолчанию 30 000). Я поставил 60 секунд, и после перезагрузки службы стали подниматься корректно. 🔥 Лайфхак: перед тем как править реестр, всегда проверяйте, нет ли проблем с производительностью или блокировками в самой системе. Увеличение таймаута — это костыль, но иногда он реально спасает. 👉 @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

👋 Привет, админы! Был случай - 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 начали рандомно падать службы, но без явных ошибок в Event Viewer. Логика подсказывала, что дело в правах или зависших сессиях, и, как оказалось, виновником была учетная запись сервиса с истекшим паролем. Чтобы быстро найти все службы, которые запускаются от нестандартных учетных записей (и проверить, не пора ли менять пароль), есть удобная команда PowerShell:

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

💡 Эта команда выведет список служб с указанием учетной записи и текущего состояния. Очень удобно перед массовым обновлением паролей или аудитом безопасности. 📌 Дополнительно советую настроить напоминание, чтобы раз в квартал проверять пароли сервисных аккаунтов — меньше будет «сюрпризов» в выходные. 💬 А у вас была ситуация, когда сервисы падали из-за паролей? Как автоматизируете их ротацию? 👉 @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 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

👋 Привет, админы! На прошлой неделе словил интересную проблему на одном из тестовых серверов — периодически пропадала связь с определёнными узлами, но пинг и 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 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

👋 Привет, админы! Ко вчерашнему посту про долгий логин, - топ-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

👋 Привет, админы! Пользователи жаловались на долгий логон на 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

👋 Привет, админы! Недавно столкнулся с ситуацией: на одном из серверов неожиданно пропал доступ к шаре. Казалось бы — стандартная история, но проблема оказалась глубже: сломалась служба 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

👋 Привет, админы! Недавно поймал интересный кейс: один из серверов на 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

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

# Задаем данные
# автор: https://t.me/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 перестали стартовать после перезагрузки, хотя руками запускались без проблем. Первое, что пришло в голову — задержка сети или зависимость от других сервисов. Проверил — всё в порядке. А вот в журнале событий нашёл интересное:

"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

🤨 Готовы проверить, насколько хорошо вы разбираетесь в основах Linux? Мы подготовили быстрый и полезный тест — всего 7 вопросов, которые помогут вам: 👉 Оценить свой текущий уровень 👉 Узнать слабые места 👉 Получить рекомендации для роста Начнём? Просто нажмите на ссылку 🔗

👋 Привет, админы! Недавно словил интересный кейс: один сервер на 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

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

🎉Коллеги, всех причастных с праздником!!! Желаю, чтобы пользователи сами читали инструкции… хотя бы иногда.» Ваш Системный Администратор Windows! 👉 @win_sysadmin