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

Недавно столкнулся с ситуацией: на одном из серверов какая-то служба не могла достучаться до 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

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

Сегодня расскажу про один неожиданный баг, с которым столкнулся на Windows Server 2022. После обновлений сервер перестал пускать пользователей по RDP. Ошибка — классическая: "The connection was denied because the user account is not authorized for remote login." Хотя у юзеров были все нужные права. 🤔

🔍 Копнул глубже — выяснилось, что в группе Remote Desktop Users внезапно исчезли все пользователи. Но в GPO права были заданы верно! Оказалось, что одно из обновлений сбросило локальные группы при конфликте с групповыми политиками.

💡 Решение:

1. Проверил GPO через gpresult /h report.html — нужные настройки есть.
2. Добавил пользователей обратно в группу через PowerShell:

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\username"

3. Чтобы автоматизировать проверку и добавление нужных участников — вот мини-скрипт:

$users = @("DOMAIN\user1", "DOMAIN\user2")
foreach ($u in $users) {
    if (-not (Get-LocalGroupMember -Group "Remote Desktop Users" -Member $u -ErrorAction SilentlyContinue)) {
        Add-LocalGroupMember -Group "Remote Desktop Users" -Member $u
        Write-Host "$u добавлен в Remote Desktop Users"
    }
}

🧩 Важно: если на сервере действует GPO, которая перезаписывает локальную группу RDP Users — добавление вручную не поможет, всё снова очистится при следующем применении политики. В таком случае правьте GPO или используйте Restricted Groups/Group Policy Preferences.

❓А у вас были кейсы, когда политики втихаря ломали RDP-доступ? Как отслеживаете такие конфликты?

👉 @win_sysadmin

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

Сегодня расскажу про один недокументированный нюанс с задачами в Планировщике Windows, с которым недавно столкнулся сам. Был у меня скрипт, который по расписанию должен запускаться от имени системной учетной записи (SYSTEM). Всё настроено правильно, вручную запускается — работает. Но вот по расписанию не срабатывает. Без ошибок, без логов, просто тишина. 🤔

🔍 После копания выяснилось: если задача запускается от SYSTEM, но в свойствах включена опция "Запускать только при входе пользователя", — она НЕ выполнится, потому что SYSTEM не входит в систему в классическом понимании.

💡 Решение:

1. Зайти в свойства задачи.
2. Переключить опцию на: "Выполнять вне зависимости от входа пользователя".
3. Обязательно включить галку "Не сохранять пароль", если используете обычную учетку (для SYSTEM это не критично).

📌 Ну и по возможности включайте логирование в задаче — пусть пишет вывод скрипта в файл, так проще отлавливать подобные "невидимые" фейлы.

💬 А у вас были странности с Task Scheduler? Может, знаете ещё тонкости, о которых стоит рассказать? Делитесь в комментариях!

👉 @win_sysadmin

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

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

🔥 Встречайте команду:

(secedit /export /cfg C:\temp\secpol.cfg) > $null
Get-Content C:\temp\secpol.cfg | Where-Object {$_ -match "Password|Lockout|Audit"} 

Что делает скрипт:

* secedit /export выгружает локальную политику безопасности в текстовый файл.
* Get-Content парсит его.
* Where-Object фильтрует строки по ключевым словам: парольная политика, блокировки, аудит.

📋 Пример вывода:

PasswordComplexity = 1
MinimumPasswordLength = 12
AuditLogonEvents = 3
LockoutBadCount = 5

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

💬 А вы как мониторите безопасность локально? Используете ли secedit, LGPO.exe, или уже всё через Intune и Defender for Endpoint?

👉 @win_sysadmin

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

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

🔥 Скрипт на PowerShell для удаления логов старше N дней:

$LogPath = "C:\Logs"
$DaysToKeep = 30

Get-ChildItem -Path $LogPath -Recurse -Include *.log |
    Where-Object { $_.LastWriteTime -lt (Get-Date).AddDays(-$DaysToKeep) } |
    Remove-Item -Force

✅ Что делает:

* Ищет все .log файлы в указанной директории (и подпапках).
* Удаляет те, что старше 30 дней.

📌 Можно засунуть в Task Scheduler, чтобы запускалось раз в неделю — и забыть про ручную уборку мусора.

💬 А как вы наводите порядок в логах? Используете ротацию (logrotate на Linux, например) или автоматизируете всё через PowerShell, bash, или какой-то агент?

👉 @win_sysadmin

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

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

🔍 Решение оказалось неочевидным: таблица маршрутизации Windows словила дичь после отключения и повторного включения второго сетевого интерфейса.

✅ Вот как я быстро проверил и подчинил ситуацию через PowerShell:

1. Смотрим таблицу маршрутов:

route print

Если видите, что маршрут к 0.0.0.0/0 уходит через нерабочий интерфейс — bingo.

2. Удаляем кривой маршрут:

route delete 0.0.0.0

3. Добавляем правильный маршрут к шлюзу:

route add 0.0.0.0 mask 0.0.0.0 <Gateway-IP> metric 10 if <Interface-Index>

Интерфейс можно узнать командой:

Get-NetIPConfiguration | Select-Object InterfaceAlias, InterfaceIndex

💡 Чтобы сделать маршрут постоянным:

route -p add 0.0.0.0 mask 0.0.0.0 <Gateway-IP> metric 10 if <Interface-Index>

Сервер снова начал видеть внешний мир, DNS заработал, всё ок.

❓Бывало у вас, что после каких-то манипуляций сеть в Windows начинает жить своей жизнью? Как боретесь?

👉 @win_sysadmin

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

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

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

✅ Быстрое решение — отключить этот механизм через реестр или GPO. Вот способ через PowerShell:

Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\Advanced" -Name "NoNetCrawling" -Value 1

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

💬 А вы отключаете сетевой кроллинг в проводнике? Или считаете, что пусть лучше всё видно, хоть и медленно? Делитесь мнением!

👉 @win_sysadmin

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

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

🔥 В таких случаях здорово помогает Get-Process в связке с Get-Counter и Sort-Object — можно быстро определить, кто именно долбит диск:

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

А если хочется ещё точнее — вот пример с использованием счётчиков производительности:

Get-Counter '\Process(*)\IO Write Bytes/sec' | 
Select-Object -ExpandProperty Countersamples | 
Sort-Object CookedValue -Descending | 
Select-Object -First 10

💡 Часто в топе — антивирус, SQL Server, или какой-нибудь рендератор типа ffmpeg.exe. Но однажды у меня неожиданно всплыл spoolsv.exe — оказалось, застрявшая очередь печати на сетевом принтере грузила систему!

💬 А как вы определяете, кто нагружает диск? Есть любимые утилиты или скрипты? Делитесь опытом!

👉 @win_sysadmin

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

Тут на хабре пишут👇

Обновление KB5058379 для Windows 10 22H2 заставляет ПК загружаться в Recovery и требовать ключ BitLocker

В середине мая Microsoft выпустила накопительное обновление безопасности KB5058379 для Windows 10 22H2 и 21H2, включая редакции LTSC/Enterprise, в рамках вторника патчей за май 2025 года. Пользователям и системным администраторам компаний с парком ПК Dell, HP или Lenovo на этих версиях ОС с новым обновлением пришлось столкнуться с перезагрузкой в Recovery и требованием ввести ключ BitLocker. Также у части пользователей начал возникать BSoD после развёртывания KB5058379.

В большинстве случаев проблема касается корпоративных клиентов, кто использует SCCM или WSUS.

Если ПК застрял на экране восстановления Windows или восстановления BitLocker («Введите ключ восстановления, чтобы снова начать») после KB5058379, нужно выполнить следующие действия:

перезагрузить ПК и зайти в BIOS/UEFI;

в настройках зайти на вкладку Security, открыть меню Virtualization или Advanced CPU Settings;

отключить опцию Intel TXT (другие название: Trusted Executio или OS Kernel DMA Support)

опцию VT for Direct I/O (или VT‑d) можно оставить включённой.

сохранить изменения и выйдите из BIOS.

Идея состоит в том, чтобы отключить Intel TXT и позволить KB5058379 завершить установку. Если правильно выполнить эти действия, то далее не будет ошибки с восстановлением BitLocker или BSOD. Примечательно, что в документе техподдержки Microsoft по‑прежнему указано, что компания не знает о каких‑либо новых проблемах с KB5058379.


https://support.microsoft.com/ru-ru/topic/13-%D0%BC%D0%B0%D1%8F-2025-%D0%B3-kb5058379-%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8-%D0%BE%D1%81-19044-5854-%D0%B8-19045-5854-0a30e9ee-5038-45dd-a5d7-70a8813a5e39

https://www.windowslatest.com/2025/05/15/windows-10-kb5058379-locks-pcs-bitlocker-recovery-triggered-on-boot-bsods/

👉 @win_sysadmin

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

Сегодняшний кейс — куда уходит свободное место на диске? Думаешь, что всё под контролем, а потом бац — и диск C: в красной зоне. Особенно часто такое встречал на серверах с включённым журналированием или забытым логированием.

📌 Вот скрипт, который помогает быстро найти топ папок и файлов, пожирающих пространство:

$path = "C:\"
Get-ChildItem -Path $path -Recurse -ErrorAction SilentlyContinue |
    Where-Object { -not $_.PSIsContainer } |
    Sort-Object Length -Descending |
    Select-Object FullName, @{Name="SizeMB";Expression={[math]::round($_.Length / 1MB, 2)}} -First 20

🔥 А если хочешь посмотреть топ папок, используй du из Sysinternals:

.\du.exe -q -l 1 C:\

(если не знаешь — du.exe можно взять отсюда)

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

💬 А как ты мониторишь место на диске? Может, у тебя есть любимый скрипт или тулза, которая всегда под рукой?

👉 @win_sysadmin

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

Знакома ситуация: вроде бы всё обновили, службы перезапустили, а сервер всё равно ведёт себя странно? Часто причина — необходим перезапуск, о котором система молчит.

💡 Чтобы не лазить вручную по реестру, вот скрипт, который проверит, требуется ли перезагрузка:

function Test-PendingReboot {
    $rebootPending = $false

    $paths = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending',
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired',
        'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations'
    )

    foreach ($path in $paths) {
        if (Test-Path $path) {
            $rebootPending = $true
            Write-Host "⏳ Pending reboot detected at: $path"
        }
    }

    return $rebootPending
}

# Пример использования:
if (Test-PendingReboot) {
    Write-Host "⚠️ Сервер требует перезагрузки!"
} else {
    Write-Host "✅ Всё чисто — перезагрузка не требуется."
}

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

🛠 Кстати, начиная с Windows Server 2019 можно также использовать Get-WindowsUpdateLog и UpdateCompliance для более глубокой аналитики.

💬 А ты как отслеживаешь pending reboot? Есть любимый способ или используешь сторонние тулзы?

👉 @win_sysadmin

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

Поймал недавно нестандартную проблему на одном из клиентских Windows 11. Пользователь жаловался: не работает печать, а в очереди — вечно зависшие задания. Перезапуск spooler'а не помогал.

Разбор показал — виноват битый драйвер, но перед этим пришлось как следует почистить очередь печати и файлы, чтобы дать системе "вдохнуть". Делюсь скриптом, который меня спас:

🔥 Полная зачистка очереди печати и временных файлов spooler:

Stop-Service -Name spooler -Force
Remove-Item -Path "C:\Windows\System32\spool\PRINTERS\*" -Force
Start-Service -Name spooler

Если директория не очищается — проверь права или вручную удали зависшие .spl и .shd файлы. После этого очередь ожила, и новые задания пошли без залипаний.

💡 А чтобы в следующий раз не искать виновника вручную, добавил логирование проблем с драйверами через Get-EventLog:

Get-EventLog -LogName System -Source "Print" -EntryType Error -Newest 20

Очень удобно — сразу видно, какой драйвер шалит.

💬 А ты как борешься с зависшей печатью? Может, есть свой скрипт или проверенный способ — делись в комментах!

👉 @win_sysadmin

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

Сегодня поймал подозрительную задачу в планировщике Windows — срабатывала каждый час и тянула PowerShell с base64-строкой.
Выглядело безобидно (UpdateTask1), но явно не из дружелюбных...

🔍 Если хочешь быстро проверить, нет ли на твоем сервере вредоносных или странных задач, вот скрипт, который я использую:

Get-ScheduledTask | ForEach-Object {
    $task = $_
    $actions = ($task.Actions | Where-Object { $_.Execute -match "powershell|cmd|wscript|cscript" })
    if ($actions) {
        [PSCustomObject]@{
            TaskName = $task.TaskName
            Path     = $task.TaskPath
            Action   = $actions.Execute + " " + $actions.Arguments
            UserId   = $task.Principal.UserId
        }
    }
} | Format-Table -AutoSize

💡 Скрипт вытаскивает все задачи, где используется PowerShell, cmd или скриптовые интерпретаторы — часто именно через них атакующие запускают свой код.
Особенно стоит насторожиться, если аргументы содержат -EncodedCommand, iex, или обращения к внешним ресурсам.

📌 Кстати, найденная мной задача маскировалась под системную и запускалась от SYSTEM — проверяй, кому доверена каждая задача.

💬 А ты проверяешь планировщик в своих аудитах? Может, есть свои лайфхаки для поиска шела?

👉 @win_sysadmin

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

Недавно прилетел мне интересный кейс: пользователи массово жаловались на медленный вход в систему. Крутилось приветствие по 3-5 минут. Оказалось, виновата политика групповых дисков, которая грузилась слишком долго.

🔍 Решение оказалось простым — нужно быстро найти проблемные политики. Вот удобный скрипт на PowerShell для проверки времени обработки GPO при входе пользователя:

Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" |
Where-Object { $_.Id -eq 4016 } |
Select-Object TimeCreated, @{n='Время загрузки GPO (сек)';e={$_.Properties[0].Value}}, @{n='Название GPO';e={$_.Properties[1].Value}} |
Sort-Object 'Время загрузки GPO (сек)' -Descending | Select-Object -First 10

✅ Этот скрипт покажет 10 самых «тяжёлых» групповых политик по времени загрузки. В моём случае лидером стала политика с забытым сетевым диском на уже не существующий файловый сервер.

💬 А вы сталкивались с подобными проблемами? Как отслеживаете медленные политики? Поделитесь в комментах!

👉 @win_sysadmin

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

Недавно столкнулся с тем, что на одном из удалённых серверов кто-то активно шёл в атаку по RDP: в логах сыпались сотни неудачных входов, и пока мониторинг не среагировал — уже появились незнакомые пользователи. Чтобы оперативно блокировать «злых» IP, я написал небольшой PowerShell-скрипт:

# Порог попыток за период (например, 5 за 10 минут)
$Threshold = 5
$Window   = (Get-Date).AddMinutes(-10)

# Получаем все события неудачных входов по RDP (EventID 4625)
$BadLogons = Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    ID      = 4625
    StartTime = $Window
} |
Where-Object {
    $_.Properties[18].Value -like '10.0.0.*' -and   # ваш диапазон RDP, если нужен
    $_.Properties[8].Value -eq '192.168.1.10' -eq $false  # исключаем локальный
} |
Select-Object @{n='IP';e={$_.Properties[18].Value}}

# Группируем по IP и фильтруем по порогу
$BadLogons | Group-Object IP | Where-Object Count -gt $Threshold | ForEach-Object {
    $ip = $_.Name
    # Проверяем, нет ли уже правила
    if (-not (Get-NetFirewallRule -DisplayName "Block-RDP-$ip" -ErrorAction SilentlyContinue)) {
        New-NetFirewallRule -DisplayName "Block-RDP-$ip" `
                            -Direction Inbound `
                            -Action Block `
                            -RemoteAddress $ip `
                            -Protocol TCP `
                            -LocalPort 3389
        Write-Host "Заблокирован IP $ip за $($_.Count) неудачных попыток"
    }
}

Этот скрипт запускаю по таймеру через Task Scheduler каждые 5 минут — и он автоматически режет «лишние» адреса.

💬 А как вы защищаете RDP? Используете RD Gateway, VPN или более хитрые решения? Поделитесь практиками в комментариях!

👉 @win_sysadmin

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

Сегодня расскажу про один лайфхак, который реально спасает, когда пользователи массово жалуются на медленную авторизацию в домене. Был у меня недавно кейс: логон на Windows затягивался до минуты, хотя сеть, казалось бы, в порядке. Виноват оказался неправильный DNS на клиентах.

🔥 Чтобы быстро проверить и исправить DNS-сервера на всех машинах в OU, можно использовать PowerShell-скрипт. Вот пример простого решения:

Get-ADComputer -Filter * -SearchBase "OU=Workstations,DC=contoso,DC=local" | ForEach-Object {
    Invoke-Command -ComputerName $_.Name -ScriptBlock {
        Get-DnsClientServerAddress | Select-Object -ExpandProperty ServerAddresses
    }
}

Этот скрипт выведет текущие DNS-сервера на всех рабочих станциях из OU. Если видишь “левых” адресов — самое время навести порядок через GPO или массово прописать нужные значения.

💬 А у тебя были ситуации, когда вся проблема оказывалась в “не том” DNS? Как обычно автоматизируешь такие проверки? Делись своими скриптами и фишками!

👉 @win_sysadmin

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

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

🔥 Вот скрипт, который меня выручил:

$servers = @("Server01", "Server02", "Server03") # список серверов
$newPass = ConvertTo-SecureString "Новый_Сложный_Пароль!" -AsPlainText -Force

foreach ($srv in $servers) {
    Invoke-Command -ComputerName $srv -ScriptBlock {
        param($pass)
        $user = [ADSI]"WinNT://./Administrator,User"
        $user.SetPassword($pass)
    } -ArgumentList $newPass
}

⚡️ Важно: убедись, что у тебя есть права на все машины и открыт WinRM!

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

💬 А у тебя были кейсы массовой смены паролей? Как автоматизируешь такие вещи? Делись опытом!

👉 @win_sysadmin

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

Сегодня расскажу про полезный трюк для тех, кто автоматизирует установку софта через PowerShell. Недавно столкнулся с задачей: массово обновить VLC на нескольких десятках машин. Обычные MSI-пакеты — это круто, но что делать с .exe-инсталляторами, у которых свои ключи для тихой установки?

🔥 Вот лайфхак — используем PowerShell и Start-Process с нужными аргументами:

Start-Process -FilePath "vlc-setup.exe" -ArgumentList "/S" -Wait

* /S — стандартный ключ для тихой установки (silent install).
* -Wait — PowerShell дождётся завершения установки.
* Можно запускать это в цикле по списку машин через Invoke-Command или PsExec.

💡 А какой софт чаще всего автоматизируете на своём парке машин? Есть любимые утилиты или хитрые ключи для silent-установки? Поделитесь опытом — уверен, найдётся немало интересных решений!

👉 @win_sysadmin