RDP-Tcp права пользователей

[Charg]

Изначальная задача - дать возможность пользователям (а лучше группам), НЕ являющими локальными администраторами ни на одном из серверов (RD Deployment (https://i.imgur.com/hxy2beT.png)), получать список терминальных сессий, слать в них сообщение и принудительно завершать сессию (force logoff).

Если издалека - давным давно во времена 2008го сервера существовала утилитка Remote Desktop Session Host Configuration, которая позволяла с помощью виндового же графического интерфейса задавать те самые права пользователям или группам, выглядело это всё вот так:
https://i.stack.imgur.com/kbq8y.png
Злобные дядьки из мелкософта, зачем-то, выпилили эту утилиту. А вот альтернативного способа добраться до этих настроек, видать, не оставили. Во всяком случае я не нашёл, буду благодарен если кто-то подскажет упущенный способ добраться до этих настроек.

В попытках докопаться до возможности менять эти права я дошел аж до WMI класса Win32_TSAccount class (https://docs.microsoft.com/en-us/windows/win32/termserv/win32-tsaccount), каждый экземпляр которого и описывает права для определенной группы.
С помощью WMI Explorer'a я вижу все эти инстансы и соответствующие им права:
https://i.imgur.com/IkchtLY.png

У класса Win32_TSAccount есть методы Delete, ModifyAuditPermissions и ModifyPermissions. Последнее в принципе должно работать, но химичить с правами на стандартных учетках не хочется потому что мало ли какие последствия вылезут да и хочется всё-таки доменную группу добавить.


Вопрос - как добавить еще один инстанс?
Или более глобальный вопрос - каким другим (возможно менее наркоманским) способом можно дать доменной группе право подключиться внутрь сессий пользователей, принудительно завершать её и отправлять сообщение внутрь сессии НЕ давая админку?

[Charg]

Небольшой апдейт - разобрался как добавить пользователя\группу как экземпляр класса Win32_TSAccount, делается это так:
$myuser = "DOMAIN\samaccountname"

$PermissionPreSet = 2
<#
0 = WINSTATION_GUEST_ACCESS => Permissions: Logon
1 = WINSTATION_USER_ACCESS => Permissions: Logon, QueryInformation, SendMessage and Connect
2 = WINSTATION_ALL_ACCESS => All RDS permissions
https://docs.microsoft.com/en-us/windows/win32/termserv/win32-tspermissionssetting-addaccount
#>

$computer = $env:COMPUTERNAME # TS SESSION HOST
$namespace = "ROOT\CIMV2\TerminalServices"
$PermissionsClassName = "Win32_TSPermissionsSetting"

$wmiTSPermissionsSetting = Get-WmiObject -Class $PermissionsClassName -ComputerName $computer -Namespace $namespace | Where-Object -FilterScript {$_.TerminalName -eq "RDP-Tcp"}
$wmiTSPermissionsSettingResult = Invoke-WmiMethod -InputObject $wmiTSPermissionsSetting -Name "AddAccount" -ArgumentList $myuser,$PermissionPreSet
Теперь, если у пользователя или группы, добавленной таким образом, есть возможность подключаться по WinRM к серверу - они могут пользоваться командлетами Send-RDUserMessage и Invoke-RDUserLogoff указывая напрямую ID сеанса + сервер с ролью Session Host, на котором хостится этот сеанс.
Только проблема в том что этот номер сеанса надо как-то узнать, и делается это так:
Get-RDUserSession -ConnectionBroker $brokerFQDN
И в ответ я получаю:
PS C:\windows\system32> Get-RDUserSession -ConnectionBroker $ConnectionBroker
Get-RDUserSession : На srv-tshost-test.company.com не развернуты службы удаленных
рабочих столов. Эту операцию можно выполнить после их развертывания. Для получения
дополнительных сведений о развертывании выполните командлет "Get-Help
New-RDVirtualDesktopDeployment" или "Get-Help New-RDSessionDeployment".
строка:1 знак:1
+ Get-RDUserSession -ConnectionBroker $ConnectionBroker
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Get-RDUserSession

При этом консольный вариант query session /server:srv-tshost-test работает, что говорит о наличии необходимого минимума прав.
А вот командлету Get-RDUserSession каких-то прав таки не хватает.

В обсуждениях на форумах я встречал различные мнения, но несколько раз (например тут (https://social.technet.microsoft.com/Forums/lync/en-US/84cccfce-9ac2-4211-8e1d-a836e3e1ab15/permissions-needed-to-query-a-connection-broker?forum=winserverTS)) натыкался на такое мнение что в процессе работы командлет Get-RDUserSession проводит целый ряд проверок "а является ли target-host частью RDS Deployment", и одна из таких проверок - командлет делает `Get-Service RDMS -Computername $target`. Я проверил и у пользователя действительно нет прав посмотреть на эту службу удалённо (PoSh говорит что служба не найдена). А если локально на сервере под этим же пользователем зайти - права уже есть.
Я не уверен на 100% в этом ли причина неработоспособности командлета Get-RDUserSession но вроде похоже не правду.
По ссылке из предыдущего абзаца даже есть обходной путь, но там слишком много ручных действий и вообще похоже больше на костыль чем решение, я бы предпочел таки дать выделенной группе пользователей все необходимые права и таки дать им возможность пользоваться "родными" средствами, а не костылить.
Есть идеи как это можно сделать?