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

Если вдруг замечаете странную активность по 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

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

Сегодня — коротко и по делу: что включить в 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, лучше узнать об этом сразу — пока не увели учётку.

Рассказываю, как настроить оповещение о неудачных входах (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

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

Если вы уже мониторите события 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, 4624, 4778 и т.п.

🎯 Есть несколько вариантов. Сегодня покажу один из самых доступных:
Windows Event Forwarding (WEF) + Event Collector.

📌 Как это работает:
- Сервер выступает как Collector (принимает логи)
- Клиенты (другие Windows-машины) — подписчики
- Всё через встроенный WinRM и GPO



🛠️ Настройка WEF в 3 шага

1. Включаем службу на Collector’е:

wecutil qc

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

2. Создаём подписку:

# Открыть Event Viewer → Subnoscriptions → Create Subnoscription

- Тип: 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 Subnoscription Manager
Значение: Server=http://COLLECTOR:5985/wsman/SubnoscriptionManager/WEC

- Включаем WinRM:

Enable-PSRemoting -Force

📊 После настройки Collector будет видеть все входы/неудачные попытки и прочие события в одном месте.

Можно дальше интегрировать:
- в SIEM (например, Wazuh, ELK, Sentinel)
- или просто логировать/оповещать через PowerShell скрипты

💬 А вы уже собираете логи централизованно? Или только на проде? Что используете — WEF, Syslog, Agent’ы?

👉 @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,
    "denoscription": "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

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

Когда ты видишь сотни логов с событиями 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

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

На днях столкнулся с интересной ситуацией: служба 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

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

Сегодня делюсь историей, которая напомнила, насколько важно внимательно читать логи (да-да, даже если их много и лень).

🧩 Проблема: 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

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

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