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

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

🧾 Суточный отчёт по пользователям 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

Как я автоматизировал очистку 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

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

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

$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

👋 Привет, админы! Был у меня недавно кейс: нужно было срочно проверить, кто и когда перезагружал сервер. Вроде бы задача простая, но в спешке иногда забываешь точные команды. Делюсь, чтобы не искать в следующий раз: 🕵️‍♂️ Ловим события перезагрузки через журнал:

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

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

👋 Привет, админы! Сегодня делюсь историей, которая напомнила, насколько важно внимательно читать логи (да-да, даже если их много и лень). 🧩 Проблема: Windows Server 2019 перестал обновляться. Центр обновлений выдавал код ошибки 0x800f0988. Вроде ничего критичного, но руководство требует, чтобы всё было "зелёным" в отчётах. 🔍 Разбор: Этот код часто указывает на битые или несовместимые компоненты в хранилище компонентов Windows (WinSxS). Сам sfc /scannow ничего не нашёл. А вот DISM подсказал:

DISM /Online /Cleanup-Image /CheckHealth

Вернул: "Повреждение обнаружено". Тогда:

DISM /Online /Cleanup-Image /RestoreHealth

Процесс шёл долго, но в итоге ошибка осталась. Копнул глубже и выяснилось: проблема в том, что удалены нужные языковые пакеты, которые почему-то требуются при установке обновлений. 💡 Решение: Переустановил нужный языковой пакет (в моем случае — en-US), перезапустил RestoreHealth, после чего обновления пошли как по маслу.

Install-Language en-US

📌 Вывод: если видите 0x800f0988, проверьте: - целостность хранилища через DISM, - наличие нужных языков (Get-WinUserLanguageList), - и не удалили ли вы что-то "ненужное" раньше для очистки WinSxS. 💬 А у вас были грабли с DISM и Windows Update? Делитесь в комментах, интересно собрать коллекцию ошибок 😊 👉 @win_sysadmin

👋 Привет, админы! На днях столкнулся с интересной ситуацией: служба 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 и в путь! 💬 А как вы чините неработающий Windows Update? Используете sfc, DISM, что-то своё? Расскажите в комментариях, будет полезно коллегам! 👉 @win_sysadmin

👋 Привет, админы! Когда ты видишь сотни логов с событиями 4625 и 4624 — хочется увидеть общую картину, а не ковыряться в логах. 🎯 Решение — визуализация в Grafana, подключённой к Elasticsearch, который использует Wazuh. 🛠️ Что тебе нужно: ✅ Рабочая инсталляция Wazuh с Elasticsearch ✅ Установленная Grafana ✅ Wazuh index (обычно wazuh-alerts-*) подключен как источник данных в Grafana 📊 Пример панели: RDP Logon Failures (Event ID 4625) Создай визуализацию с такими настройками: - Query: data.win.system.eventID:4625 AND data.win.event_data.LogonType:"10" - Metric: Count - Group by: - data.win.event_data.IpAddress.keyword — по IP - data.win.event_data.TargetUserName.keyword — по пользователю - @timestamp — по времени (в Histogram) 📌 Это даст тебе: - Топ IP-адресов, которые ломятся по RDP - Частоту атак по времени - Учетки, на которые идёт перебор 📈 Дополнительно: - Успешные входы (4624) — для сравнения - RDP session start (4778) и end (4779) — активность пользователей - GeoIP — можно прикрутить GeoIP-плагин в Elasticsearch и рисовать карту атакующих 🔒 Бонус: Threshold + Alerting Если за последние 10 минут по одному IP > 10 ошибок входа — можно задать алерт в Grafana и слать в Telegram, Discord, email, webhook. 💬 А вы визуализируете логи безопасности или только хардкор логами и текстами? Что используете — Grafana, Kibana, Zabbix? 👉 @win_sysadmin

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

👋 Привет, админы! Если у вас больше одного сервера, вручную выискивать RDP-брутфорс или другие попытки взлома — гиблое дело. Нам нужен централизованный сбор логов, особенно событий типа 4625, 4624, 4778 и т.п. 🎯 Есть несколько вариантов. Сегодня покажу один из самых доступных: Windows Event Forwarding (WEF) + Event Collector. 📌 Как это работает: - Сервер выступает как Collector (принимает логи) - Клиенты (другие Windows-машины) — подписчики - Всё через встроенный WinRM и GPO 🛠️ Настройка WEF в 3 шага 1. Включаем службу на Collector’е:

wecutil qc

Это создаст необходимую подписку и включит службу Windows Event Collector. 2. Создаём подписку:

# Открыть Event Viewer → Subscriptions → Create Subscription

- Тип: Collector initiated - Event log: Security - Filter: Id=4625;4624;4778 - Advanced: выбрать нужные LogonType, если хотите только RDP 3. Настраиваем GPO на клиентах: В GPO для машин, откуда хотим собирать логи: - Computer Configuration → Administrative Templates → Windows Components → Event Forwarding - Configure target Subscription Manager Значение: Server=http://COLLECTOR:5985/wsman/SubscriptionManager/WEC - Включаем WinRM:

Enable-PSRemoting -Force

📊 После настройки Collector будет видеть все входы/неудачные попытки и прочие события в одном месте. Можно дальше интегрировать: - в SIEM (например, Wazuh, ELK, Sentinel) - или просто логировать/оповещать через PowerShell скрипты 💬 А вы уже собираете логи централизованно? Или только на проде? Что используете — WEF, Syslog, Agent’ы? 👉 @win_sysadmin

👋 Привет, админы! Если вы уже мониторите события 4625 (неудачные входы по RDP), следующий шаг — автоматическая блокировка IP-адресов, которые слишком активно пытаются попасть на сервер. Вот скрипт, который парсит события и блокирует агрессивные IP:

# RDPBlockBadIPs.ps1
$events = Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625;
    StartTime = (Get-Date).AddMinutes(-15)
} | Where-Object {
    $_.Properties[10].Value -eq '10' # Logon Type 10 = RDP
}

$badIPs = $events |
    Group-Object { $_.Properties[18].Value } |
    Where-Object { $_.Count -ge 5 } |  # Порог блокировки
    Select-Object -ExpandProperty Name

foreach ($ip in $badIPs) {
    if ($ip -and ($ip -match '\d+\.\d+\.\d+\.\d+')) {
        Write-Host "Блокирую IP: $ip"
        New-NetFirewallRule -DisplayName "Block RDP Brute $ip" `
                            -Direction Inbound `
                            -RemoteAddress $ip `
                            -Action Block `
                            -Protocol TCP `
                            -LocalPort 3389 `
                            -Profile Any
    }
}

📌 Что делает скрипт: - Ищет за последние 15 минут события 4625 по RDP - Вычисляет IP-адреса с 5+ неудачами - Создаёт firewall-правило на блокировку 💡 Можно запустить по расписанию через Scheduled Task, как в предыдущем посте. А если хочется очистку — можно добавить автоудаление блоков по TTL. ⚠️ Важно: не переусердствуйте — может прилететь блокировка легитимного VPN или админа. Лучше держать whitelist. 💬 А вы используете автоматические блокировки? Или предпочитаете fail2ban на edge-хостах/Linux-бастионках? 👉 @win_sysadmin

👋 Привет, админы! Если на сервер идёт брутфорс по RDP, лучше узнать об этом сразу — пока не увели учётку. Рассказываю, как настроить оповещение о неудачных входах (4625) с Logon Type 10 (то есть RDP) через PowerShell + Scheduled Task. 📌 Сначала скрипт, который проверяет события и пишет лог/шлёт алерт:

# RDPBruteCheck.ps1
$Events = Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625;
    StartTime = (Get-Date).AddMinutes(-5)
} | Where-Object {
    $_.Properties[10].Value -eq '10' # RDP Logon Type
}

if ($Events.Count -gt 0) {
    $msg = "$($Events.Count) неудачных попыток входа по RDP за последние 5 минут!"
    # Можно заменить на email, Telegram API, SIEM и т.п.
    Add-Content -Path "C:\Scripts\RDPBruteLog.txt" -Value "$(Get-Date): $msg"
}

⚙️ Потом создаём запланированное задание, чтобы скрипт запускался каждые 5 минут:

$action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-File C:\Scripts\RDPBruteCheck.ps1"
$trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(1) -RepetitionInterval (New-TimeSpan -Minutes 5) -RepetitionDuration ([TimeSpan]::MaxValue)
Register-ScheduledTask -TaskName "MonitorRDPBrute" -Action $action -Trigger $trigger -RunLevel Highest -User "SYSTEM"

🛠️ Можно доработать под: - Email-уведомления (Send-MailMessage) - Telegram-бота - Интеграцию с Zabbix/PRTG/ELK 💬 А как вы реагируете на попытки брутфорса? Настраиваете уведомления или полагаетесь на внешние средства защиты? 👉 @win_sysadmin

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

💬 А вы централизуете такие события? Sysmon, WEF, SIEM, что в арсенале? 👉 @win_sysadmin

👋 Привет, админы! Если вдруг замечаете странную активность по RDP — сессии отваливаются, логов много, сервер грузится — самое время проверить, кто брутфорсит. Вот быстрый способ вытащить неудачные попытки входа по RDP через события:

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4625
} | Where-Object {
    $_.Properties[10].Value -eq '10' # Logon Type 10 = RDP
} | Select-Object TimeCreated,
                      @{Name='Username';Expression={$_.Properties[5].Value}},
                      @{Name='IP';Expression={$_.Properties[18].Value}} |
Sort-Object TimeCreated -Descending | Select-Object -First 20

📌 Покажет: - когда была попытка - откуда (IP) - под каким логином пытались зайти 👮‍♂️ Можно быстро зафайрволить источник, добавить в blacklist или передать в SIEM. 🛡️ Плюс к этому — рекомендую включить защиту учётных записей от перебора пароля:

net accounts /lockoutthreshold:5 /lockoutduration:15 /lockoutwindow:15

💬 А как вы отслеживаете попытки взлома по RDP? Вручную, через сторонние средства, или всё уже централизовано? 👉 @win_sysadmin

👋 Привет, админы! Продолжаем тему автологина — только теперь наоборот. Сегодня покажу, как отключить автоматический вход в Windows, если его кто-то однажды настроил (и забыл). 🔧 Всё просто — правим те же ключи в реестре:

$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty -Path $RegPath -Name "AutoAdminLogon" -Value "0"
Remove-ItemProperty -Path $RegPath -Name "DefaultPassword" -ErrorAction SilentlyContinue

Если хотите полностью зачистить следы, можно ещё убрать DefaultUsername и DefaultDomainName, особенно если вход теперь идёт по другим учеткам или через домен:

Remove-ItemProperty -Path $RegPath -Name "DefaultUsername" -ErrorAction SilentlyContinue
Remove-ItemProperty -Path $RegPath -Name "DefaultDomainName" -ErrorAction SilentlyContinue

🎯 После этого автологин не будет срабатывать, и пользователь снова увидит окно входа. 👁️ Лайфхак: если нужно массово проверить, включен ли автологин на серверах, можно пробежаться скриптом по списку машин и вытащить AutoAdminLogon:

Invoke-Command -ComputerName (Get-Content servers.txt) -ScriptBlock {
    Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "AutoAdminLogon"
}

💬 А вы используете какие-нибудь средства для аудита автологина на серверах или рабочих станциях? Может быть, сканеры GPO, Defender for Endpoint, Intune? 👉 @win_sysadmin

👋 Всем айтишный привет! Был недавно кейс: нужно настроить автологин для одного стендового сервера в изолированной сети — без домена, без пользователей, просто чтобы поднимался нужный софт после перезагрузки. Решается это через редактирование реестра:

$RegPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty -Path $RegPath -Name "AutoAdminLogon" -Value "1"
Set-ItemProperty -Path $RegPath -Name "DefaultUsername" -Value "UserName"
Set-ItemProperty -Path $RegPath -Name "DefaultPassword" -Value "UserPassword"
Set-ItemProperty -Path $RegPath -Name "DefaultDomainName" -Value "$env:COMPUTERNAME"

⚠️ Обратите внимание: пароль хранится в открытом виде в реестре (DefaultPassword), поэтому использовать это стоит только в безопасной среде. 🛡️ Есть ещё один способ — через netplwiz, но он не автоматизируется скриптами. А если хотите чуть безопаснее — можно использовать специальные учетные записи без доступа к сети и минимальными правами. 🔄 После внесения изменений — либо ребут, либо shutdown /r /t 0 для применения. 💬 А используете ли вы автологин в каких-нибудь сценариях? Или строго по политике — никаких паролей в реестре? 👉 @win_sysadmin

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

Confirm-SecureBootUEFI

Если вернёт True — Secure Boot активен. False — выключен. А если вылетает ошибка, значит либо UEFI не используется, либо железо/OS не поддерживают Secure Boot. 🔒 Хочу напомнить, что Secure Boot — один из базовых элементов защиты от загрузки неподписанных (вредоносных) загрузчиков. Особенно актуально в среде, где есть автозагрузка ISO, PXE или кастомные live-образы. 📦 А чтобы прогнать это по сети — можно использовать PowerShell Remoting:

Invoke-Command -ComputerName SERVER01 -ScriptBlock { Confirm-SecureBootUEFI }

Либо через Enter-PSSession, если хотите вручную посмотреть на конкретной машине. 💬 А у вас включен Secure Boot на проде? Или предпочитаете отключать из-за драйверов и кастомного софта? Делитесь опытом! 👉 @win_sysadmin

👋 Всем айтишный привет! Недавно столкнулся с задачей: надо было массово проверить статус служб на нескольких серверах. Причём не просто глянуть, работают или нет, а убедиться, что определённые критически важные сервисы (типа w32time, WinRM, TermService) действительно в состоянии Running. 🛠️ Вот скрипт, который упростил мне жизнь:

$servers = @("server1", "server2", "server3")
$servicesToCheck = @("w32time", "WinRM", "TermService")

foreach ($server in $servers) {
    Write-Host "🔍 Проверка $server" -ForegroundColor Cyan
    foreach ($service in $servicesToCheck) {
        $status = Get-Service -ComputerName $server -Name $service -ErrorAction SilentlyContinue
        if ($status.Status -eq 'Running') {
            Write-Host "$service: OK" -ForegroundColor Green
        } else {
            Write-Host "$service: НЕ РАБОТАЕТ!" -ForegroundColor Red
        }
    }
    Write-Host ""
}

🔥 Удобно, когда нужно быстро прогнать по десятку машин. Особенно помогает на продакшене, где простой службы — это потенциальный инцидент. 💬 А у вас есть свои заготовки для массовой проверки сервисов или состояния системы? Делитесь в комментах, обсудим! 👉 @win_sysadmin