RDP Diagnostic Tool: Swiss Army Knife для диагностики удалённых рабочих столов

Представьте ситуацию: пятница, 17:55, звонит директор и сообщает, что половина сотрудников не может подключиться по RDP к терминальному серверу. Вы открываете консоль, набираете одну команду — и через 30 секунд у вас полный отчёт: что сломалось, где именно и как починить. Именно это делает RDP Diagnostic Tool (https://github.com/paulmann/RDP-Diagnostic-Tool) — инструмент корпоративного класса для диагностики, мониторинга и оптимизации инфраструктуры Remote Desktop Protocol.

1. Что такое RDP Diagnostic Tool и зачем он нужен

1.1. Проблема, которую он решает

RDP — это не просто «открытый порт 3389». За каждым сеансом удалённого рабочего стола стоит целый стек технологий: ядерные драйверы termdd.sys и tdtcp.sys, аутентификация через CredSSP и NLA, виртуальные каналы, GPU-сессии RemoteFX, политики лицензирования и многое другое. Когда что-то ломается — найти причину вручную означает часы в Event Viewer, реестре и командной строке.

RDP Diagnostic Tool автоматизирует всё это в единый, структурированный процесс.

1.2. Ключевые возможности

1.3. Кому это нужно

Инструмент создан для системных администраторов, архитекторов инфраструктуры и инженеров поддержки, работающих в средах с Remote Desktop Services (RDS), RDSH-фермами, VDI и Azure Virtual Desktop.

2. Архитектура инструмента

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

flowchart TD
    A([👤 Администратор]) --> B[Invoke-RdpDiagnostic]
    B --> C{Режим диагностики}
    C -->|Quick ~30 сек| D[Базовые проверки]
    C -->|Full ~3-5 мин| E[Полный аудит]
    C -->|Deep ~15+ мин| F[Глубокий анализ]

    D --> G[Сеть · Порт 3389 · Firewall]
    E --> G
    E --> H[Аутентификация · CredSSP · NLA · TLS]
    E --> I[Лицензирование · GPO · Профили]
    E --> J[GPU · RemoteFX · VRAM]
    F --> G
    F --> H
    F --> I
    F --> J
    F --> K[WPR Traces · ETW Events · Wireshark]
    F --> L[Memory Dumps · Kernel Debug]

    G --> M{Diagnostic Core Engine}
    H --> M
    I --> M
    J --> M
    K --> M
    L --> M

    M --> N[Report Generator]
    N --> O[Console]
    N --> P[JSON]
    N --> Q[HTML-отчёт]
    N --> R[CSV]

Ключевой принцип архитектуры: инструмент работает только в режиме чтения по умолчанию. Никаких изменений в системе без явного флага -Remediate. Это делает его безопасным для применения на продакшн-серверах без согласования с Change Management.

3. Системные требования

3.1. Минимальные и рекомендуемые

3.2. Требования для удалённой диагностики

Для диагностики удалённых хостов на целевых машинах должен быть включён WinRM. Это стандартное требование PowerShell Remoting — без него инструмент не сможет подключиться к удалённому серверу.

⚠️ Важно: Запуск всегда выполняется от имени администратора. Обычный пользователь не имеет доступа к ядерным счётчикам, реестру TermService и ETW-трассировкам.

4. Установка

4.1. Схема процесса установки

flowchart LR
    START([Начало]) --> CHECK{PowerShell 7+\nустановлен?}
    CHECK -->|Нет| INSTALL_PS[Установить PowerShell 7\nhttps://aka.ms/powershell]
    CHECK -->|Да| METHOD{Выбор метода\nустановки}
    INSTALL_PS --> METHOD

    METHOD -->|Быстро| DIRECT[Метод 1\nПрямая загрузка]
    METHOD -->|Разработчик| GIT[Метод 2\nGit Clone]
    METHOD -->|Корпоратив| GPO[Метод 3\nGPO Deployment]

    DIRECT --> UNBLOCK[Unblock-File]
    GIT --> UNBLOCK
    GPO --> VERIFY

    UNBLOCK --> POLICY[Set-ExecutionPolicy\nRemoteSigned]
    POLICY --> VERIFY[Проверка установки]
    VERIFY --> DONE([✅ Готово к работе])

4.2. Метод 1 — Прямая загрузка (рекомендуется)

Самый простой способ — одна команда в PowerShell 7, запущенном от администратора:

# Загружаем последний релиз
$url = "https://github.com/paulmann/RDP-Diagnostic-Tool/releases/latest/download/RDP-Tool.ps1"
$dest = "$env:ProgramFiles\RDP-Diagnostic-Tool\RDP-Tool.ps1"
New-Item -ItemType Directory -Force -Path (Split-Path $dest)
Invoke-WebRequest -Uri $url -OutFile $dest

# Снимаем блокировку загруженного файла
Unblock-File -Path $dest

# Устанавливаем политику выполнения
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force

4.3. Метод 2 — Git Clone (для разработчиков и продвинутых пользователей)

Если вы хотите иметь полный исходный код и возможность обновляться через git pull:

# Клонируем репозиторий
git clone https://github.com/paulmann/RDP-Diagnostic-Tool.git
cd RDP-Diagnostic-Tool

# Запускаем из директории проекта
.\Invoke-RdpDiagnostic.ps1 -Target localhost -Mode Quick

Репозиторий находится по адресу: https://github.com/paulmann/RDP-Diagnostic-Tool

4.4. Метод 3 — GPO Deployment (для корпоративных сред)

Для развёртывания на сотнях серверов через Group Policy используйте логон-скрипт GPO. Подробная инструкция с примерами политик приведена на странице вики (https://github.com/paulmann/RDP-Diagnostic-Tool/wiki/Installation).

4.5. Настройка WinRM для удалённой диагностики

Если планируете диагностировать удалённые хосты — выполните на целевом сервере:

# Включаем WinRM с HTTPS-listener
Enable-PSRemoting -Force
winrm quickconfig -transport:https

# Или через групповую политику для всего домена:
# Computer Configuration → Windows Settings → Security Settings
# → Windows Firewall → Allow inbound WinRM (HTTPS)

5. Первый запуск и режимы работы

5.1. Три режима диагностики

flowchart TD
    QUICK["⚡ Quick Mode\n~30 секунд"]
    FULL["🔍 Full Mode\n~3–5 минут"]
    DEEP["🧪 Deep Mode\n~15+ минут"]

    QUICK -->|"Включает"| Q1[Проверка порта 3389]
    QUICK -->|"Включает"| Q2[Базовая аутентификация]
    QUICK -->|"Включает"| Q3[Статус TermService]

    FULL -->|"Всё из Quick, плюс"| F1[Лицензии RDS]
    FULL -->|"Всё из Quick, плюс"| F2[Сертификаты и GPO]
    FULL -->|"Всё из Quick, плюс"| F3[GPU и профили]
    FULL -->|"Всё из Quick, плюс"| F4[Ядерные драйверы]

    DEEP -->|"Всё из Full, плюс"| D1[WPR/ETW трассировки]
    DEEP -->|"Всё из Full, плюс"| D2[Wireshark захват пакетов]
    DEEP -->|"Всё из Full, плюс"| D3[Memory Dumps]
    DEEP -->|"Всё из Full, плюс"| D4[Kernel Debugging]

5.2. Базовый синтаксис

# Проверка локального хоста (быстрый режим)
.\Invoke-RdpDiagnostic.ps1 -Target localhost -Mode Quick

# Полная диагностика удалённого сервера
.\Invoke-RdpDiagnostic.ps1 -Target "server01.corp.local" -Mode Full -Verbose

# Диагностика с HTML-отчётом
.\Invoke-RdpDiagnostic.ps1 -Target "rdsh-farm01" -Mode Full `
    -OutputFormat HTML -ReportPath C:\Reports\

# Диагностика с альтернативными учётными данными
$cred = Get-Credential
.\Invoke-RdpDiagnostic.ps1 -Target "server02.corp.local" `
    -Mode Full -Credential $cred

5.3. Все параметры командной строки

6. Практические сценарии использования

6.1. Сценарий: «Пользователи не могут подключиться»

Это самый частый инцидент. Алгоритм диагностики:

flowchart TD
    INCIDENT([🚨 Инцидент:\nRDP недоступен]) --> QUICK[Запускаем Quick Mode]
    QUICK --> CHECK{Порт 3389\nслушает?}

    CHECK -->|Нет| TERMSVC{TermService\nзапущен?}
    TERMSVC -->|Нет| START_SVC[Start-Service TermService]
    TERMSVC -->|Да| REGISTRY[Проверяем реестр\nfDenyTSConnections = 0]

    CHECK -->|Да| FIREWALL{Firewall\nблокирует?}
    FIREWALL -->|Да| FW_FIX[Enable-NetFirewallRule\n-DisplayGroup 'Remote Desktop']
    FIREWALL -->|Нет| AUTH{Ошибка\nаутентификации?}

    AUTH -->|CredSSP| CREDSSP[Проверяем патч\nCVE-2018-0886]
    AUTH -->|NLA| NLA[Проверяем уровень\nбезопасности RDP]
    AUTH -->|Нет| SESSIONS[Проверяем лимит\nсессий / лицензии]

    START_SVC --> DONE([✅ Проблема решена])
    REGISTRY --> DONE
    FW_FIX --> DONE
    CREDSSP --> DONE
    NLA --> DONE
    SESSIONS --> DONE

Команда для этого сценария:

# Шаг 1 — быстрая проверка, что вообще не так
.\Invoke-RdpDiagnostic.ps1 -Target "rdsh01.corp.local" -Mode Quick -Verbose

# Шаг 2 — если нашли проблему, смотрим что исправить (WhatIf — безопасный режим)
.\Invoke-RdpDiagnostic.ps1 -Target "rdsh01.corp.local" -Mode Quick -Remediate -WhatIf

# Шаг 3 — применяем исправление
.\Invoke-RdpDiagnostic.ps1 -Target "rdsh01.corp.local" -Mode Quick -Remediate

6.2. Сценарий: «Медленные RDP-сессии, тормозит картинка»

Когда пользователи жалуются на лаги и артефакты изображения — проблема, скорее всего, в GPU или сети. Здесь нужен Full Mode с акцентом на производительность:

# Диагностика производительности с подробным выводом
.\Invoke-RdpDiagnostic.ps1 -Target "rdsh-farm01" -Mode Full `
    -Verbose -OutputFormat HTML -ReportPath "C:\Reports\"

# Только GPU-диагностика (пропускаем всё остальное)
.\Invoke-RdpDiagnostic.ps1 -Target "rdsh-farm01" -Mode Full `
    -SkipModules Audio, Licensing

Инструмент проверит:

• Использование VRAM на GPU (счётчики \GPU Engine(*enqueue*)\Utilization Percentage)
• Статус RemoteFX-адаптера через WMI-класс Msvm_Synthetic3DDisplayController
• Разделы GPU-P (GPU Partitioning) для Hyper-V сред
• Пропускную способность сети и задержки RDP PDU-пакетов

6.3. Сценарий: «Плановый аудит безопасности RDSH-фермы»

Перед аудитом или после инцидента ИБ — запускаем полное сканирование всех серверов фермы и получаем сводный HTML-отчёт:

# Массовая диагностика нескольких серверов
$servers = @("rdsh01", "rdsh02", "rdsh03", "rdsh04")
$cred = Get-Credential "CORP\rdp-audit-svc"

foreach ($srv in $servers) {
    .\Invoke-RdpDiagnostic.ps1 -Target $srv -Mode Full `
        -Credential $cred `
        -OutputFormat HTML `
        -ReportPath "C:\Audit\$(Get-Date -f 'yyyy-MM-dd')"
}

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

6.4. Сценарий: «Глубокая трассировка зависающих сессий»

Если сессии зависают случайным образом и стандартная диагностика ничего не показывает — подключаем Deep Mode с захватом ETW-трассировок:

# Deep mode — захват WPR-трассировки во время воспроизведения проблемы
.\Invoke-RdpDiagnostic.ps1 -Target "rdsh01" -Mode Deep `
    -OutputFormat JSON -ReportPath "C:\DeepDiag\"

В Deep Mode инструмент автоматически запускает Windows Performance Recorder (WPR) с профилем Microsoft-Windows-TerminalServices-*, воспроизводит нагрузку, останавливает захват и сохраняет .etl-файл в указанную папку. Файл открывается в Windows Performance Analyzer (WPA) для детального анализа CPU, GPU и I/O.

7. Интерпретация результатов

7.1. Структура вывода в консоль

text[2026-04-02 15:03:41] RDP Diagnostic Tool v1.0.0
[2026-04-02 15:03:41] Target: rdsh01.corp.local | Mode: Full
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[PASS] Network      Port 3389 listening          TCP 0.0.0.0:3389
[PASS] Network      Firewall rule active         Remote Desktop (TCP-In)
[PASS] Auth         NLA enabled                  SecurityLayer = 2
[WARN] Auth         CredSSP patch missing        KB4103723 not installed
[PASS] Sessions     Active sessions: 12          Max: 50
[FAIL] Kernel       termdd.sys unsigned!         Version 10.0.17763.1
[PASS] GPU          VRAM utilization: 34%        2.7 GB / 8 GB
[WARN] License      RDS CALs: 48/50              2 remaining

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SUMMARY: 5 PASS | 2 WARN | 1 FAIL
Report saved: C:\Reports\rdsh01_2026-04-02_150341.html

7.2. Расшифровка статусов

textflowchart LR
    PASS["✅ PASS\nНорма"] -->|"Значение в допустимых пределах"| OK["Действий не требуется"]
    WARN["⚠️ WARN\nПредупреждение"] -->|"Потенциальная проблема"| PLAN["Запланировать исправление"]
    FAIL["❌ FAIL\nОтказ"] -->|"Критическая проблема"| IMMEDIATE["Немедленное вмешательство"]

    PLAN --> REMEDIATE{"-Remediate\nдоступен?"}
    IMMEDIATE --> REMEDIATE
    REMEDIATE -->|Да| AUTO["Автоматическое\nисправление"]
    REMEDIATE -->|Нет| MANUAL["Ручное исправление\nпо документации"]

7.3. Типичные предупреждения и их смысл

8. Форматы отчётов и интеграция

8.1. HTML-отчёт для руководства

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

.\Invoke-RdpDiagnostic.ps1 -Target "rdsh-farm01" -Mode Full `
    -OutputFormat HTML -ReportPath "C:\Reports\"
# Откроет: C:\Reports\rdsh-farm01_2026-04-02_150000.html

8.2. JSON-формат для интеграции с мониторингом

JSON позволяет передавать результаты в системы мониторинга — Zabbix, Prometheus, ELK Stack, Grafana или SIEM:

# Получаем JSON и отправляем в API мониторинга
$result = .\Invoke-RdpDiagnostic.ps1 -Target "rdsh01" -Mode Quick `
    -OutputFormat JSON | ConvertFrom-Json

# Пример: отправка в Zabbix Sender
if ($result.Summary.FailCount -gt 0) {
    Send-ZabbixTrap -Server "zabbix.corp.local" `
        -Key "rdp.diagnostic.failures" `
        -Value $result.Summary.FailCount
}

8.3. CSV-формат для Excel-аналитики

Удобен для построения трендов и анализа в Excel или Power BI:

# Сохраняем CSV, открываем в Excel
.\Invoke-RdpDiagnostic.ps1 -Target "rdsh01" -Mode Full `
    -OutputFormat CSV -ReportPath "C:\Reports\"

8.4. Схема интеграции в корпоративный мониторинг

flowchart TD
    TOOL[RDP Diagnostic Tool] -->|"JSON output"| PIPELINE{Пайплайн\nобработки}

    PIPELINE -->|"Alerts"| ZABBIX[Zabbix / Prometheus\nAlertmanager]
    PIPELINE -->|"Logs"| ELK[ELK Stack\nElasticSearch + Kibana]
    PIPELINE -->|"Reports"| POWERBI[Power BI\nReal-time Dashboard]
    PIPELINE -->|"Tickets"| ITSM[ServiceNow / Jira\nAuto-ticket creation]

    ZABBIX --> ONCALL[📱 On-Call инженер]
    ELK --> ANALYST[📊 Аналитик безопасности]
    POWERBI --> MANAGER[📋 IT-руководитель]
    ITSM --> HELPDESK[🎫 Help Desk]

9. Безопасность: что нужно знать перед применением

9.1. Принцип минимальных привилегий

Инструмент требует прав администратора, но сам по себе ничего не меняет без явного флага -Remediate. Рекомендуется создать отдельную сервисную учётную запись только для диагностики с минимально необходимыми правами:

# Создаём выделенную учётную запись для диагностики
New-ADUser -Name "rdp-diag-svc" -Description "RDP Diagnostic Service Account" `
    -PasswordNeverExpires $true -AccountPassword (ConvertTo-SecureString "..." -AsPlainText -Force)

# Добавляем только в группу Event Log Readers и Performance Log Users
Add-ADGroupMember -Identity "Event Log Readers" -Members "rdp-diag-svc"
Add-ADGroupMember -Identity "Performance Log Users" -Members "rdp-diag-svc"

9.2. Базовый чек-лист безопасности RDP

Инструмент проверяет все эти пункты автоматически, но полезно понимать, что именно он ищет:

• NLA (Network Level Authentication) — пользователь аутентифицируется до создания полноценной сессии; защищает от атак типа «pre-auth RCE»
• TLS 1.2+ — шифрование канала; TLS 1.0/1.1 давно скомпрометированы
• CredSSP CVE-2018-0886 — критическая уязвимость в механизме делегирования учётных данных; закрывается патчем
• Порт 3389 не должен быть открыт напрямую в интернет — только через RD Gateway или VPN
• Event ID мониторинг — ID 4625, 4648, 1149 для обнаружения brute-force атак

9.3. Just-In-Time доступ (JIT)

Для максимальной безопасности Enhancement-Roadmap инструмента включает поддержку JIT-доступа (https://github.com/paulmann/RDP-Diagnostic-Tool/wiki/Security): RDP-подключение разрешается только на время конкретной задачи, затем автоматически блокируется. Это исключает постоянно открытые сессии-«двери» в сеть.

10. Планы развития и что будет дальше

Проект активно развивается. Согласно Enhancement Roadmap (https://github.com/paulmann/RDP-Diagnostic-Tool/wiki/Enhancement-Roadmap), в версии 1.1.0 и далее планируется:

timeline
    title Дорожная карта RDP Diagnostic Tool
    section v1.0.0 (Апрель 2026)
        Текущий релиз : Полный стек диагностики
                      : Quick / Full / Deep режимы
                      : HTML / JSON / CSV / Console отчёты
                      : GPU и RemoteFX диагностика
    section v1.1.0 (Q3 2026)
        ITSM интеграция : ServiceNow webhook
                        : Jira auto-ticket creation
        Kubernetes : Helm chart для K8s
                   : Containerized diagnostics
    section v1.2.0 (Q4 2026)
        ML аналитика : Predictive failure detection
                     : Anomaly detection (Isolation Forest)
                     : LSTM Time Series прогноз
    section v2.0.0 (2027)
        Power BI : Real-time RDP dashboards
                 : Azure Monitor integration
                 : Cross-tenant diagnostics

Особенно интересна ML-составляющая: планируется сбор телеметрии в Azure Event Hub → Azure Stream Analytics → модель машинного обучения, которая предсказывает сбои RDP-инфраструктуры за 30+ минут до их возникновения. Это переход от реактивного устранения инцидентов к к предиктивной эксплуатации — когда система сама предупреждает о проблеме ещё до того, как первый пользователь успевает позвонить в helpdesk.

11. Участие в разработке и сообщество

11.1. Как внести вклад

RDP Diagnostic Tool — проект с открытым исходным кодом под лицензией MIT. Это означает, что вы можете свободно использовать, модифицировать и распространять его. Если вы хотите участвовать в разработке — процесс максимально стандартизирован (подробности на странице Contributing: https://github.com/paulmann/RDP-Diagnostic-Tool/wiki/Contributing):

flowchart LR
    FORK[Fork репозитория\nна GitHub] --> BRANCH[Создать feature-ветку\nfeature/название-фичи]
    BRANCH --> CODE[Написать код\nпо PowerShell Style Guide]
    CODE --> TEST[Запустить тесты\nPester 5.x test suite]
    TEST --> PR{Тесты\nпрошли?}
    PR -->|Да| SUBMIT[Submit Pull Request\nна main ветку]
    PR -->|Нет| FIX[Исправить\nи повторить]
    FIX --> TEST
    SUBMIT --> REVIEW[Code Review\nот мейнтейнера]
    REVIEW --> MERGE[✅ Merge в main]

11.2. Соглашения по именованию веток

Проект придерживается чёткой конвенции для названий веток:

11.3. Требования к коду PowerShell

Все функции должны содержать стандартный блок документации:

#Requires -Version 7.0
#Requires -RunAsAdministrator

<#
.SYNOPSIS
    Краткое описание функции.

.DESCRIPTION
    Полное описание. Author: Mikhail Deynekin <mid1977@gmail.com>
    https://deynekin.com

.PARAMETER Target
    Имя хоста или IP-адрес для диагностики.

.EXAMPLE
    Invoke-RdpDiagnostic -Target "rdsh01" -Mode Quick
#>

12. Автоматизация: запуск по расписанию

12.1. Плановый мониторинг через Task Scheduler

Один из самых практичных паттернов использования — регулярный автоматический аудит всех RDP-серверов с рассылкой отчётов:

# Создаём задачу в планировщике: ежедневно в 03:00
$action = New-ScheduledTaskAction -Execute "pwsh.exe" -Argument @"
    -NonInteractive -File "C:\Tools\RDP-Diagnostic-Tool\Invoke-RdpDiagnostic.ps1"
    -Target rdsh01,rdsh02,rdsh03
    -Mode Full
    -OutputFormat HTML
    -ReportPath "C:\Reports\Daily"
"@

$trigger = New-ScheduledTaskTrigger -Daily -At "03:00"
$principal = New-ScheduledTaskPrincipal -UserId "CORP\rdp-diag-svc" -RunLevel Highest

Register-ScheduledTask -TaskName "RDP Daily Audit" `
    -Action $action -Trigger $trigger -Principal $principal

12.2. Интеграция в CI/CD пайплайн

Для организаций, использующих DevOps-практики, инструмент можно встроить в GitHub Actions или Azure DevOps — например, для автоматической проверки сред после деплоя:

# .github/workflows/rdp-health-check.yml
name: RDP Infrastructure Health Check
on:
  schedule:
    - cron: '0 1 * * *'   # Каждый день в 01:00 UTC
  workflow_dispatch:         # Ручной запуск

jobs:
  rdp-audit:
    runs-on: windows-2022
    steps:
      - name: Download RDP Diagnostic Tool
        run: |
          $url = "https://github.com/paulmann/RDP-Diagnostic-Tool/releases/latest/download/RDP-Tool.ps1"
          Invoke-WebRequest -Uri $url -OutFile "RDP-Tool.ps1"
          Unblock-File "RDP-Tool.ps1"

      - name: Run diagnostics
        run: |
          .\RDP-Tool.ps1 -Target $env:RDSH_TARGET `
            -Mode Full -OutputFormat JSON `
            -ReportPath ".\reports\"

      - name: Upload report artifact
        uses: actions/upload-artifact@v4
        with:
          name: rdp-diagnostic-report
          path: reports/
          retention-days: 30

      - name: Fail if critical issues found
        run: |
          $report = Get-Content ".\reports\*.json" | ConvertFrom-Json
          if ($report.Summary.FailCount -gt 0) {
            Write-Error "Critical RDP issues detected: $($report.Summary.FailCount) failures"
            exit 1
          }

12.3. Схема полного цикла автоматизации

flowchart TD
    SCHEDULER([⏰ Task Scheduler\nили CI/CD]) -->|"Ежедневно 03:00"| TOOL[Invoke-RdpDiagnostic\nFull Mode · Все серверы]

    TOOL --> PARSE{Анализ\nрезультатов}

    PARSE -->|"FailCount = 0\nWarnCount = 0"| GREEN[✅ Всё в норме\nОтчёт в архив]
    PARSE -->|"WarnCount > 0"| YELLOW[⚠️ Предупреждения\nEmail команде]
    PARSE -->|"FailCount > 0"| RED[❌ Критические ошибки\nNемедленная эскалация]

    RED --> ITSM[Создать тикет\nServiceNow / Jira]
    RED --> ALERT[SMS / Telegram / PagerDuty\nOn-Call инженер]
    RED --> REMEDIATE{Автоисправление\nдоступно?}

    REMEDIATE -->|Да| AUTO[-Remediate флаг\nАвтоматическое исправление]
    REMEDIATE -->|Нет| MANUAL[Ручное вмешательство\nпо инструкции]

    AUTO --> RECHECK[Повторная проверка\nчерез 5 минут]
    RECHECK -->|Исправлено| CLOSE[Закрыть тикет]
    RECHECK -->|Не исправлено| ESCALATE[Эскалация\nна следующий уровень]

    YELLOW --> REPORT[HTML-отчёт\nна почту команды]
    GREEN --> REPORT
    CLOSE --> REPORT

13. Сравнение с альтернативами

Прежде чем принять решение о внедрении любого инструмента, полезно понимать его место среди альтернатив:

Вывод: для команд, работающих преимущественно с Windows Server и PowerShell, RDP Diagnostic Tool закрывает 90% потребностей диагностики без каких-либо затрат и без установки тяжёлых агентов.

14. Быстрый старт: от нуля до первого отчёта за 5 минут

Для тех, кто любит действовать сразу — концентрированный гайд:

flowchart LR
    S1["1️⃣ PowerShell 7\nустановлен?\nhttps://aka.ms/powershell"] --> S2["2️⃣ Запустить PowerShell\nот Администратора"]
    S2 --> S3["3️⃣ Скачать инструмент\nInvoke-WebRequest..."]
    S3 --> S4["4️⃣ Unblock-File"]
    S4 --> S5["5️⃣ Первый запуск\n-Mode Quick -Target localhost"]
    S5 --> S6["✅ Получить результат\nза 30 секунд"]

Полный текст команд за 5 шагов:

# Шаг 1: Открыть PowerShell 7 от администратора, затем:

# Шаг 2: Скачать инструмент
$dest = "$env:ProgramFiles\RDP-Diagnostic-Tool"
New-Item -ItemType Directory -Force -Path $dest | Out-Null
Invoke-WebRequest -Uri "https://github.com/paulmann/RDP-Diagnostic-Tool/releases/latest/download/RDP-Tool.ps1" `
    -OutFile "$dest\Invoke-RdpDiagnostic.ps1"

# Шаг 3: Разблокировать файл
Unblock-File -Path "$dest\Invoke-RdpDiagnostic.ps1"

# Шаг 4: Установить политику выполнения
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser -Force

# Шаг 5: Запустить первую диагностику!
& "$dest\Invoke-RdpDiagnostic.ps1" -Target localhost -Mode Quick -Verbose

Через 30 секунд вы увидите полный отчёт о состоянии RDP на локальном сервере.

Заключение

RDP Diagnostic Tool — это именно тот инструмент, которого не хватало в арсенале каждого Windows-администратора. Он не пытается заменить весь стек мониторинга — он решает одну конкретную задачу, но решает её исчерпывающе: от поверхностной проверки порта до трассировки ядерных драйверов и захвата сетевых пакетов.

Три вещи выделяют его среди аналогов:

1. Принцип read-only по умолчанию — никаких неожиданных изменений на продакшн-серверах без явного разрешения.
2. Единый точка входа — одна команда Invoke-RdpDiagnostic, три режима, четыре формата вывода, поддержка любых целевых хостов в домене.
3. Открытый код — вы точно знаете, что происходит внутри, можете адаптировать под свою инфраструктуру и предложить улучшения.

Ссылки по теме:

• Репозиторий проекта: https://github.com/paulmann/RDP-Diagnostic-Tool
• Полная документация (Wiki): https://github.com/paulmann/RDP-Diagnostic-Tool/wiki
• Установка: https://github.com/paulmann/RDP-Diagnostic-Tool/wiki/Installation
• Конфигурация: https://github.com/paulmann/RDP-Diagnostic-Tool/wiki/Configuration
• Руководство по использованию: https://github.com/paulmann/RDP-Diagnostic-Tool/wiki/Usage
• Безопасность: https://github.com/paulmann/RDP-Diagnostic-Tool/wiki/Security
• Устранение неполадок: https://github.com/paulmann/RDP-Diagnostic-Tool/wiki/Troubleshooting
• Дорожная карта: https://github.com/paulmann/RDP-Diagnostic-Tool/wiki/Enhancement-Roadmap
• Сайт автора: https://deynekin.com

Статья подготовлена на основе официальной документации проекта RDP Diagnostic Tool v1.0.0. Актуально для Windows 10-11 / Windows Server 2019–2025, PowerShell 7.0+.