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

На днях ловил интересную проблему с GPO. Пользователь жалуется: после перезагрузки пропадают закреплённые приложения на панели задач. Сначала подумал — баг профиля. Но нет, причина оказалась куда изощрённее: групповая политика переустанавливает taskbar layout при каждом входе.

🔍 Если используете XML-модификацию панели задач (через LayoutModification.xml), и она привязана в GPO, то при каждом входе пользователя этот layout применяется заново. В итоге все ручные закрепления — сносятся.

📌 Решение:

1. Если цель — задать стартовую конфигурацию и разрешить пользователям её менять, используйте параметр:

   User Configuration → Administrative Templates → Start Menu and Taskbar → Do not use the taskbar layout configured in XML
   

Установите в Enabled.

2. Или вместо постоянного применения layout — разворачивайте XML один раз с помощью скрипта при создании профиля.

💡 Ещё вариант — вообще отказаться от XML и использовать PowerShell-скрипты для закрепления приложений. Например:

$apps = @(
    "Microsoft.Edge",
    "Microsoft.Windows.Explorer"
)

foreach ($app in $apps) {
    $AUMID = (Get-StartApps | Where-Object { $_.Name -eq $app }).AppID
    if ($AUMID) {
        (New-Object -ComObject Shell.Application).NameSpace('shell:::{3080F90E-D7AD-11D9-BD98-0000947B0257}').ParseName($AUMID).InvokeVerb('pin to taskbar')
    }
}

🧩 Такие нюансы часто всплывают, когда пытаешься автоматизировать «по красоте», а GPO делает всё по-своему.

💬 А вы как настраиваете панель задач в корпоративной среде? Через XML, скрипты или руками?

👉 @win_sysadmin

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

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

🔥 Вот простой PowerShell для создания пользователей по CSV:

Import-Csv "C:\Scripts\users.csv" | ForEach-Object {
    $name = "$($_.FirstName) $($_.LastName)"
    $sam = $_.SamAccountName
    $ou = "OU=Users,DC=contoso,DC=local"
    
    New-ADUser -Name $name `
               -GivenName $_.FirstName `
               -Surname $_.LastName `
               -SamAccountName $sam `
               -UserPrincipalName "$[email protected]" `
               -Path $ou `
               -AccountPassword (ConvertTo-SecureString "P@ssw0rd123" -AsPlainText -Force) `
               -Enabled $true

    Add-ADGroupMember -Identity "Domain Users" -Members $sam
}

CSV-шка выглядит так:

FirstName,LastName,SamAccountName
Ivan,Ivanov,i.ivanov
Petr,Petrov,p.petrov

🛡 Конечно, пароль временный — дальше юзер меняет при первом входе. Плюс можно докрутить добавление в разные группы, создание home-директории и т.д.

💬 А как вы автоматизируете ввод новых пользователей? Делаете через PowerShell, сторонние тулзы или вручную? Поделитесь своим способом!

👉 @win_sysadmin

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

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

🔥 Суть кейса: на нескольких новых машинах автоматически отключался экран через 1 минуту простоя, несмотря на выставленные GPO "никогда не выключать дисплей".

🤨 Что оказалось? Групповая политика исправно настраивала Computer Configuration > Policies > Administrative Templates > System > Power Management, но не трогала "Console lock display off timeout".

Эта настройка по умолчанию скрыта и не отображается в GUI! Но её можно включить в реестр или через GPO, а потом управлять через PowerShell:

powercfg /change monitor-timeout-ac 15

А вот как вывести текущие значения:

powercfg /query SCHEME_CURRENT SUB_VIDEO

💡 Если экран тухнет через минуту после блокировки — проверьте именно Console lock display off timeout. Это не то же самое, что просто "turn off display".

✅ Решение: через GPO включил видимость параметра и задал нужное значение. Проблема ушла.

💬 А у вас бывали случаи, когда политика "применена", но система ведет себя по-своему? Какие грабли были с powercfg и энергосбережением?

👉 @win_sysadmin

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

Недавно наткнулся на интересный момент при обновлении сертификатов на IIS — думаю, многим пригодится.

🛠 Когда меняешь сертификат вручную через GUI, всё просто. Но если нужно обновить десятки сайтов на одном сервере, то ручками — долго и больно. Решение? Конечно, PowerShell!

Вот скрипт, который автоматически находит и заменяет SSL-сертификат по thumbprint на всех сайтах в IIS:

Import-Module WebAdministration

$oldThumb = "111122223333444455556666777788889999AAAA"
$newThumb = "AAAA999988887777666655554444333322221111"

$sites = Get-ChildItem IIS:\Sites

foreach ($site in $sites) {
    $bindings = Get-WebBinding -Name $site.Name | Where-Object { $_.protocol -eq "https" }
    
    foreach ($binding in $bindings) {
        $bindingInfo = $binding.bindingInformation
        $cert = Get-Item "cert://LocalMachine/My/$oldThumb"
        
        if ($cert) {
            Write-Host "Обновляю сертификат на сайте $($site.Name)..."
            # Удаляем старый биндинг
            Remove-WebBinding -Name $site.Name -BindingInformation $bindingInfo -Protocol "https"
            # Добавляем с новым thumbprint
            New-WebBinding -Name $site.Name -Protocol "https" -Port 443 -IPAddress "*" -HostHeader $binding.Host
            Push-Location IIS:\SslBindings
            New-Item "0.0.0.0!443!$($binding.Host)" -Thumbprint $newThumb -SSLFlags 1
            Pop-Location
        }
    }
}

🔥 Работает быстро и чётко. Особенно выручает в связке с автоматической выдачей сертификатов (например, через ACMESharp или Win-ACME).

💬 А вы как автоматизируете обновление сертификатов? Через PowerShell, Certbot, Group Policy или руками по старинке?

👉 @win_sysadmin

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

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

🕵️‍♂️ В итоге нашёл внедрение в процесс через WMI. Да-да, старый добрый WMI стал каналом для персистентности малвари. Чтобы выявить такие вещи, добавил себе в регулярный аудит вот такую проверку:

Get-WmiObject -Namespace "root\subscription" -Class __FilterToConsumerBinding |
Select-Object -Property Filter, Consumer

А дальше уже идёт разбор через:

Get-WmiObject -Namespace "root\subscription" -Class __EventFilter
Get-WmiObject -Namespace "root\subscription" -Class CommandLineEventConsumer

⚠️ Если видите странные команды, непонятные пути, особенно с PowerShell или cmd.exe — повод для расследования.

Ну и напоследок

- Регулярно просматривайте WMI-события.
- Включите логирование WMI через Event ID 5861/5860 (Microsoft-Windows-WMI-Activity/Operational).
- Используйте Sysmon — он хорошо ловит подобные фокусы (Event ID 1 + родительские процессы).

💬 А вы мониторите WMI в своих инфраструктурах? Есть ли какие-то интересные кейсы? Поделитесь опытом!

👉 @win_sysadmin

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

Бывает, нужно быстро понять, какие задачи по расписанию крутятся на сервере. Особенно когда сервер ведёт себя странно, а в логах — тишина. У меня был случай, когда скрипт сливал логи на сторону, а запускался через Task Scheduler под безобидным именем UpdateCheck.

🔥 Вот командлет, который мне помог всё быстро найти:

Get-ScheduledTask | Where-Object {$_.TaskPath -notlike '\Microsoft*'} |
Select-Object TaskName, TaskPath, State

А если хотите подробности (что запускается и от какого имени), то:

Get-ScheduledTask | ForEach-Object {
    $info = $_
    Get-ScheduledTaskInfo -TaskName $info.TaskName -TaskPath $info.TaskPath | Select-Object @{Name='Name';Expression={$info.TaskName}}, @{Name='User';Expression={$info.Principal.UserId}}, @{Name='LastRunTime';Expression={$_.LastRunTime}}, @{Name='NextRunTime';Expression={$_.NextRunTime}}, @{Name='Status';Expression={$_.LastTaskResult}}
}

📌 Советую раз в месяц гонять такой скрипт по всем серверам. Лучше найти лишнее самому, чем ждать сюрпризов от пользователей (или вредоносов).

💬 А вы как мониторите задания планировщика? Есть ли скрипты или автоматизация для этого?

👉 @win_sysadmin

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

Вспомнил один случай пару лет назад: групповые политики перестали применяться, хотя GPO на месте, политики не менялись, сеть ок. На клиенте — никаких ошибок в обычных логах.

💥 А виноват оказался вот такой зверь:
Ошибка 0x8007000d: Data is invalid при выполнении gpupdate /force.

Что помогло:

1. Проверка журналов через Event Viewer:
Applications and Services Logs -> Microsoft -> Windows -> GroupPolicy -> Operational
Там вылезло: "The processing of Group Policy failed. Data is invalid."

2. Удаление сломанных GPO-кэшей на клиенте:

Remove-Item -Path "C:\ProgramData\Microsoft\Group Policy\History\*" -Recurse -Force
gpupdate /force

3. Также проверил, не повреждён ли Registry.pol:

del /f /q "%SystemRoot%\System32\GroupPolicy\Machine\Registry.pol"

(после этого gpupdate сам пересоздаёт его по актуальным политикам)

✅ После этих действий GPO стали применяться нормально.

📌 На всякий случай теперь мониторю и кэш, и наличие ошибок 7016 / 7017 в журнале GroupPolicy.

💬 А у вас были кейсы с внезапной порчей групповых политик? Чем лечили?

👉 @win_sysadmin

🎉Коллеги, всех причастных с праздником!!!

Желаю, чтобы пользователи сами читали инструкции… хотя бы иногда.»

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

👉 @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

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

Недавно словил интересную ситуацию: доменный контроллер начал подвисать при логоне пользователей. Логи пустые, нагрузка на CPU и RAM в норме. 🤔 Виновник нашёлся не сразу — забитый журнал безопасности (Security Log)!

Когда журнал переполнен и стоит политика “Do not overwrite events”, новые события просто не пишутся, и AD начинает чудить.

📌 Быстро проверить состояние журнала можно так:

Get-WinEvent -ListLog Security | Select-Object LogName, RecordCount, MaximumSizeInBytes, IsLogFull

А чтобы очистить журнал без захода в Event Viewer:

wevtutil cl Security

Ну и чтобы не ловить такие сюрпризы — ставьте автоматическую очистку или увеличьте размер лога:

wevtutil sl Security /ms:524288000

(пример — 500 МБ).

💬 Было ли у вас, что из-за логов система начинала вести себя странно? И какой размер логов держите на контроллерах?

👉 @win_sysadmin

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

Недавно словил интересный кейс: один сервер на Windows Server 2019 внезапно перестал ставить обновления. Центр обновлений ругался на «поврежденные компоненты», но sfc /scannow показывал, что всё ок.

Тут меня выручила DISM — старый добрый инструмент для починки образа системы. Ниже рабочая связка команд:

DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth

⚡ Что делают эти команды:

- CheckHealth — быстро проверяет, есть ли повреждения.
- ScanHealth — делает глубокую диагностику (долго, но надёжно).
- RestoreHealth — чинит поврежденные компоненты через Центр обновлений или указанный источник.

В моем случае именно RestoreHealth вылечил систему, и обновления пошли как по маслу.

💡Если сервер без интернета, можно указать свой ISO-образ Windows:

DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim /LimitAccess

А вы как чините такие баги? DISM, Repair-Install или сразу в продакшн с головой и reinstall? 😄

👉 @win_sysadmin

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

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

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

"The service did not start due to a logon failure"

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

🔧 Чтобы быстро проверить все службы, запускаемые не от LocalSystem, я накатил простой PowerShell-скрипт:

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

Так сразу видно, какие службы работают от доменных или локальных учёток.
Если находите неактуальные — обновляйте пароль через:

sc.exe config "ServiceName" obj= "DOMAIN\User" password= "NewPassword"

После обновления не забудьте перезапустить сервис:

Restart-Service -Name "ServiceName"

⚡ В итоге за 10 минут нашли и починили всё, без долгого копания в GUI.

💬 А вы проверяете периодически пароли сервисных учёток? Есть ли у вас автоматизация для таких случаев?

👉 @win_sysadmin

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

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

Вот скрипт:

# Задаем данные
# автор: https://t.iss.one/win_sysadmin
$ServiceAccount = "DOMAIN\ServiceUser"
$NewPassword = "NewSecurePassword123!"
$Servers = @("Server1","Server2","Server3")  # список серверов

foreach ($Server in $Servers) {
    Write-Host "Обновляю службы на $Server..." -ForegroundColor Cyan
    $services = Get-WmiObject Win32_Service -ComputerName $Server | Where-Object { $_.StartName -eq $ServiceAccount }
    foreach ($svc in $services) {
        Write-Host "  -> Обновляем $($svc.Name) ($($svc.DisplayName))" -ForegroundColor Yellow
        $result = sc.exe \\$Server config $($svc.Name) obj= $ServiceAccount password= $NewPassword
        if ($result -like "*[SC] ChangeServiceConfig SUCCESS*") {
            Restart-Service -Name $svc.Name -ComputerName $Server -Force
            Write-Host "     Перезапущено." -ForegroundColor Green
        } else {
            Write-Host "     Ошибка при обновлении!" -ForegroundColor Red
        }
    }
}

Работа скрипта:

- Берёт список серверов.
- Находит службы, которые работают под указанной учёткой.
- Меняет пароль и сразу перезапускает сервис.

Можно легко адаптировать под CSV, чтобы брать серверы и учётки из файла.

👉 @win_sysadmin

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

Недавно поймал интересный кейс: один из серверов на Windows Server 2019 неожиданно перестал обновляться. Центр обновлений крутился без конца, а в WindowsUpdate.log — стандартный "ничего полезного".

Оказалось, что проблема была в битом кэше обновлений. Решение оказалось простым, но спасло несколько часов:

net stop wuauserv
net stop bits
Remove-Item -Recurse -Force C:\Windows\SoftwareDistribution\*
net start bits
net start wuauserv

После этого сервер спокойно подтянул все обновления.

👉 Маленький лайфхак: если часто сталкиваетесь с зависаниями обновлений, автоматизируйте этот процесс. Например:

$services = "wuauserv","bits"
Stop-Service $services -Force
Remove-Item -Recurse -Force C:\Windows\SoftwareDistribution\*
Start-Service $services
Write-Host "Кэш обновлений очищен!"

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

💬 А вы как решаете проблемы с зависшими обновлениями? Ручками или автоматизацией? Может, используете WSUS или сторонние решения?

👉 @win_sysadmin

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

Недавно столкнулся с ситуацией: на одном из серверов неожиданно пропал доступ к шаре. Казалось бы — стандартная история, но проблема оказалась глубже: сломалась служба LanmanServer (серверная служба, отвечающая за SMB).

Чтобы не лазить каждый раз руками в services.msc, сделал себе маленький скрипт для быстрой проверки и перезапуска:

$service = Get-Service -Name "LanmanServer"
if ($service.Status -ne "Running") {
    Write-Host "Служба Server не запущена. Пробую запустить..."
    Start-Service -Name "LanmanServer"
    Start-Sleep -Seconds 3
    Get-Service -Name "LanmanServer"
} else {
    Write-Host "Служба Server работает нормально."
}

Теперь запускаю его при малейших подозрениях на проблемы с доступом к шарам. Удобно, особенно если комбинировать с уведомлением (например, через Telegram-бота).

💡 Кстати, иногда помогает ещё и перерегистрация библиотек SMB:

regsvr32 srvsvc.dll

А вы мониторите состояние SMB-службы? Может, кто-то автоматизировал перезапуск через Task Scheduler при падении? Делитесь кейсами!

👉 @win_sysadmin

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

Пользователи жаловались на долгий логон на RDS-сервер. Вроде и ресурсов хватает, и сеть нормальная — а сессия грузится по минуте.

Покопался в логах и наткнулся на то, что отрабатывает куча лишних GPO, в том числе старые скрипты входа, которые уже давно никому не нужны.

Быстро проверить, какие политики реально применяются, помогла вот такая команда:

gpresult /h C:\Temp\GPO_Report.html

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

А еще можно через PowerShell собрать сводку по GPO и времени логина:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-GroupPolicy/Operational';ID=5312} |
Select-Object TimeCreated, Message |
Sort-Object TimeCreated -Descending |
Select-Object -First 20

Так я нашел пару древних скриптов, которые тормозили загрузку профиля. Удалил — и логон снова за 10 секунд! 🚀

💬 А у вас часто встречаются такие "призраки прошлого" в GPO? Как вы отслеживаете, что реально используется, а что пора выкинуть?

👉 @win_sysadmin

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

Ко вчерашнему посту про долгий логин, - топ-10 команд для быстрой диагностики проблем логина на Windows-серверах и рабочих станциях.

Если пользователи жалуются на долгий вход или подвисания - вот с чего начинаю копать:


1. Какие политики реально применяются:

gpresult /h C:\Temp\GPO_Report.html

Отчет в HTML сразу покажет все GPO и их статус.

2. Время применения групповых политик:

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-GroupPolicy/Operational';ID=5312} |
Select-Object TimeCreated, Message

3. Анализ процессов при логоне:

Get-Process | Sort-Object StartTime -Descending | Select-Object -First 20

Можно понять, что запускается последним и тормозит старт.

4. Диагностика профиля пользователя:

Get-WmiObject Win32_UserProfile | Select LocalPath, LastUseTime, Special

Выявляем битые или старые профили.

5. События медленного входа (Winlogon):

Get-WinEvent -LogName 'Microsoft-Windows-Winlogon/Operational' | 
Select TimeCreated, Id, Message -First 20

6. Проверка сетевых задержек (DC):

nltest /dsgetdc:DOMAINNAME

Быстро видим, к какому контроллеру цепляется клиент.

7. Тест производительности сети:

Test-NetConnection DC_NAME -Port 389

Проверка доступности LDAP-порта.

8. Проверка кешированных профилей:

dir "C:\Users" | Sort-Object LastWriteTime

9. Время выполнения скриптов входа:

Get-WinEvent -LogName 'Microsoft-Windows-Shell-Core/Operational' | 
? {$_.Message -like "*Logon Script*"} | Select TimeCreated, Message

10. Чтение журналов User Profile Service:

Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' |
Select TimeCreated, Id, Message -First 20

🔥 Эти команды помогают понять: проблема в политике, профиле, сети или скриптах.

💬 А вы как диагностируете долгий логон? Может, у кого-то есть свои must-have команды? Давайте соберем подборку!

👉 @win_sysadmin

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

На днях попался мне интересный случай: один сервер Windows Server 2019 начал жаловаться пользователям на «медленный отклик» при входе в систему. Логи чистые, CPU и RAM в норме. Но вот вход в RDP занимал секунд 30–40.

Оказалось, что виноват переизбыточный автозапуск — в профилях пользователей накопилось куча мусора: OneDrive, Teams, Zoom и ещё парочка «добрых» помощников стартовали при каждом логоне.

📌 Вот как я быстро вычистил это через PowerShell:

Get-CimInstance Win32_StartupCommand |
Select-Object Name, Command, Location, User |
Sort-Object Name

Эта команда покажет всё, что стартует при входе, включая системные и пользовательские записи.
Дальше можно удалить ненужное:

Get-CimInstance Win32_StartupCommand | Where-Object {$_.Name -like "*Teams*"} | Remove-CimInstance

После чистки вход в систему стал занимать 8–10 секунд.
Так что совет — периодически проверяйте автозапуск, особенно на терминальных серверах.

💬 А вы чистите автозагрузку централизованно через GPO или вручную на серверах?

👉 @win_sysadmin

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

На прошлой неделе словил интересную проблему на одном из тестовых серверов — периодически пропадала связь с определёнными узлами, но пинг и RDP в это время работали. Сначала подумал на фаервол или кривые ACL, но оказалось, что дело в DNS-кэше Windows.

Иногда DNS-клиент кеширует устаревшие записи, и мы получаем «битые» IP-адреса. Решается это быстро:

🔥 Сбросить DNS-кэш:

Clear-DnsClientCache

🔥 Посмотреть, что сейчас в кеше:

Get-DnsClientCache | Sort-Object -Property RecordName

🔥 Полный перезапуск сервиса DNS-клиента:

Restart-Service -Name "Dnscache"

После очистки всё заработало, а в логах появились актуальные адреса. Совет — включайте это в чек-лист, если сталкиваетесь с «призрачными» проблемами сети.

💬 А вы чаще чистите DNS-кэш вручную или автоматизируете это через GPO/скрипты?

👉 @win_sysadmin

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

Сегодня словил забавный (но потенциально опасный) момент: после обновления Windows Server 2022 один из сервисов перестал стартовать при загрузке, хотя в Services.msc он стоит на Automatic.

🔍 Оказалось, что проблема в том, что Windows теперь иногда «умно» откладывает запуск сервисов, помеченных как Automatic (Delayed Start), особенно если система решает, что «надо разгрузить старт».

💡 Решение нашлось простое: проверяем и меняем тип запуска на обычный Automatic через PowerShell:

Set-Service -Name "Имя_сервиса" -StartupType Automatic

А если надо массово проверить и поправить сразу несколько сервисов, которые почему-то стоят на Delayed Start:

Get-Service | Where-Object { $_.StartType -eq 'AutomaticDelayedStart' } |
ForEach-Object { Set-Service -Name $_.Name -StartupType Automatic }

После перезагрузки — всё взлетело как надо 🚀.

💬 А вы как относитесь к Delayed Start? Используете для оптимизации загрузки или всегда ставите чистый Automatic?

👉 @win_sysadmin

Используете VPN? Или только планируете внедрять его в корпоративную сеть?
Узнайте, как избежать ошибок при выборе типа VPN для разных задач на вебинаре OTUS 13 августа в 19:00!


❓Как выбрать правильный тип VPN? Поговорим о том, какой сервис нужен для разных задач: офис-офис, облако, удалённые сотрудники
❓Основы IPSec: почему этот фреймворк остаётся одним из самых надежных для построения защищённых VPN-соединений, несмотря на свою сложность
❓Типы VPN и их сравнение: что выбрать для своей инфраструктуры? Почему не все решения одинаково полезны?

Спикер: Николай Колесов — Эксперт ТАС вендора по решениям routing&switching и data center, с опытом работы в самых передовых решениях от Cisco, Juniper и Huawei.

Скидка 7% на любой курс OTUS и подарки для тех, кто примет участие в вебинаре.

Не упусти шанс! Присоединяйся к вебинару, чтобы быть уверенным в защите своей корпоративной сети и не допустить ошибок, которые могут дорого стоить бизнесу!
📝 Записывайтесь на вебинар: https://tglink.io/b6f1c9dda02a

Реклама. ООО "ОТУС ОНЛАЙН-ОБРАЗОВАНИЕ". ИНН 9705100963. erid: 2W5zFGbpZMa