Как включить удалённый рабочий стол RDP
Клиент и сервер присутствуют по умолчанию во всех версиях Windows. Для запуска клиента не требуется дополнительная настройка.
Что касается сервера, то он может быть отключён и/или доступ к порту RDP может быть заблокирован файерволом.
Как включить удалённый рабочий стол на Windows 10 в командной строке
Нажмите Win+r и введите:
SystemPropertiesRemote
В открывшемся окне выберите «Разрешить удалённые подключения к этому компьютеру»:
При необходимости добавьте пользователей, которые могут удалённо подключиться, щёлкнув «Выбрать пользователей». Члены группы «Администраторы» получают доступ автоматически:
Чтобы правильно добавить пользователя, введите его имя:
И нажмите кнопку «Проверить имена»:
Команду SystemPropertiesRemote также можно запустить в командной строке, либо в PowerShell.
Как включить удалённый рабочий стол на Windows 10 в графическом интерфейсе
На устройстве, с которого вы собираетесь подключиться, откройте меню Пуск и щёлкните значок Параметры:
Выберите Система:
На вкладке «Удалённый рабочий стол» включите соответствующий ползунок. Также вы можете выбрать пользователей, которые могут подключаться удалённо к компьютеру.
Подтвердите выбранное действие:
Дополнительно вы можете включить настройки:
- Оставлять мой компьютер в режиме бодрствования для соединения, когда он подключён к электросети
- Сделать мой компьютер обнаруживаемым в частных сетях для активации подключения с удалённым доступом
Кликнув «Дополнительные параметры» вы увидите настройки для изменения стандартного порта RDP и других свойств подключения.
Описанные выше способы также будут работать и на Windows Server 2019. В дополнении к ним есть ещё несколько способов включения RDP на Windows Server 2019.
Как включить удалённый рабочий стол на Windows Server 2019 в PowerShell
Разрешение службы удалённых рабочих столов в Windows Server 2019 быстрее сделать в PowerShell, чем в графическом интерфейсе. Для этого параметра мы будем использовать командлет Set-ItemPropery для изменения параметра флага реестра.
Запустите сеанс PowerShell от имени администратора. Для этого нажмите Win+x и выберите Windows PowerShell (администратор):
Затем выполните следующую команду:
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 0
Файервол Windows не разрешает удалённые подключения к RDP Нам нужно настроить файервол, чтобы он разрешал удалённые подключения RDP, для этого выполните команду:
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Для отключения RDP запустите:
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -name "fDenyTSConnections" -value 1
Настройка RDP веб клиента HTML5 на RDS Windows Server 2016
Несмотря на то, что Microsoft за последние несколько лет портировала свой RDP клиент под различные платформы (iOS, macOS, Android, есть даже отдельное UWP приложение для Windows 10), многим пользователям хотелось бы получать удаленный RDP доступ к RDS серверам и опубликованным приложениям из любого браузера. Для этих целей Microsoft несколько лет разрабатывала отдельный Remote Desktop Web Client на базе HTML5. Совсем недавно была выпушена первая официальная версия RD Web Client. В этой статье мы рассмотрим, как установить и настроить Remote Desktop Web Client и использовать его для доступа к RemoteApp на RDS сервере с Windows Server 2016 из обычного браузера.
Using Remote Desktop Shadow from the Windows GUI
You can connect to a user session using or directly from Server Manager graphical console. To do it, open the Server Manager console on the RDS server, go to the Remote Desktop Services section -> select your collection, for example .
The list on the right will contain a list of users who have sessions on this RDS server. Right-click on the user session you want, select Shadow from the drop-down menu.
You can only connect to an active user session. If the session is in a disconnected state (due to the RDS session limit/timeout settings), you cannot connect to such a session:
Shadow Error - The specified session is not connected.
A window with Shadow connection parameters will appear. You can either View or Control a user’s RDP session. You can also check Prompt for user consent option.
If this option is checked, the following request appears in the user’s RDP session:
Remote Monitoring Request woshub\administrator is requesting to view your session remotely. Do you accept the request?
If the user confirms the connection, the administrator will see his desktop in View mode, but won’t be able to interact with it.
Tip. To disconnect from a user session and exit the Shadow mode, press on the workstation or on the RDS server (if no alternative combinations are not set).
If a user rejects the administrative Shadow RDS connection, the following message appears:
Shadow Error: The operator or administrator has refused the request.
You cannot use the tsadmin.msc graphical snap-in from Windows Server 2008 R2 for shadow connections to RDP sessions on newer versions of Windows Server.
Shadow Error: The Group Policy setting is configured to require the user’s consent. Verify the configuration of the policy settings.
If you need to audit RDS shadow connection events for user sessions, use the following filtered events from the Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational log:
- Event ID 20508: Shadow View Permission Granted;
- Event ID 20503: Shadow View Session Started;
- Event ID 20504: Shadow View Session Stopped.
Исправляем ошибку access denied for user root localhost
1. Подключение с другого хоста
Сначала рассмотрим как работать с Phpmyadmin. Это намного проще для начинающих и тех, кто не любит работать в терминале. Откройте Phpmyadmin, авторизуйтесь в программе с правами root и перейдите на вкладку «Учетные записи пользователей»:
Здесь, вы увидите, кроме обычных полей, поле «имя хоста», которое указывает с какого хоста может подключаться пользователь. Если в этом поле написано localhost, значит этот пользователь может авторизоваться только с локальной машины. Также, в этом поле может находиться IP адрес, с которого есть разрешение или символ %, который означает, что пользователь может подключаться с любого IP.
Чтобы изменить права для пользователя, нужно нажать на ссылку «Редактировать привилегии» для него, на открывшейся странице перейдите на вкладку «Информация об учетной записи»:
Затем установите в поле «Имя хоста» значение «Любой хост» чтобы разрешить этому пользователю авторизоваться с любого IP. Если вы хотите разрешить только определенный IP, выберите «Использовать текстовое поле» и укажите нужный адрес или подсеть:
После этого останется нажать кнопку «Вперед» чтобы сохранить настройки. Если вам нужно чтобы был доступ и с локального IP, и с другого, то необходимо создать еще одного пользователя. После этого вы сможете авторизоваться от имени этого пользователя.
Теперь рассмотрим другой способ решить ошибку 1045 access denied for user root localhost, с помощью терминала. Это немного проще, поскольку вам нужно только выполнить несколько команд:
mysql
> UPDATE SET Host=’%’ WHERE Host=’localhost’ AND User=’имя_пользователя’; > UPDATE SET Host=’%’ WHERE Host=’localhost’ AND User=’имя_пользователя’; > FLUSH PRIVILEGES;
Уже после этого, вы можете подключаться к серверу баз данных с любого другого компьютера и не получите никаких ошибок. Вместо символа %, можно указать нужный ip или localhost, если ограничение нужно вернуть обратно.
2. Неверный пароль root
Иногда случается, что при установке базы данных пароль для root задается, но вы его не знаете. Поскольку это главный пользователь и если вы не можете войти от его имени, то вы не сможете ничего исправить. Сначала попробуйте авторизоваться от имени root в системе и подключиться к базе без пароля:
mysql
Иногда это работает. Если не сработало, остановите службу mysql и запустите ее без проверки безопасности, а затем попробуйте снова:
systemctl stop mysqld mysqld —skip-grant-tables mysql
> USE mysql; > UPDATE user SET Password=PASSWORD (‘ваш_пароль’) where USER=’root’; > FLUSH PRIVILEGES;
Еще можно попытаться выдать права над всеми таблицами нашему пользователю, если это необходимо:
> GRANT ALL ON *.* TO ‘root’@’localhost’ WITH GRANT OPTION;
Установка Terminal Services Manager
Запускаем исполняемый файл, я это делаю на своей тестовой виртуальной машине с Windows Server 2019. Первое что вас спросят, это в каком режиме вы решили установить утилиту TSM. На выбор будет два варианта:
- Install for all users — Установка для всех пользователей данного компьютера
- Install for me only — Установка Terminal Services Manager исключительно для вас на данном компьютере
Далее вам нужно принять лицензионное соглашение, выбрав пункт «I accept the agreement» и нажать «next».
На следующем шаге вы можете изменить каталог установки TSM, я оставлю все по умолчанию.
Оставьте галку на пункте «Create a desktop shortcut», чтобы у вас был создан ярлык на рабочем столе.
Для завершения инсталляции Terminal Services Manager нажмите кнопку «Install».
Запускаем Terminal Services Manager.
Решение проблемы
Ошибка вроде очевидная, что не включен RDP доступ, если бы это был рядовой сервер я бы понял, но тут служба удаленного доступа точно работала и была включена, так как на данный сервер так же распространялась групповая политика делающая, это автоматически, я проверил применение GPO, все было хорошо. Первым делом я полез смотреть логи Windows, это можно сделать классическим методом или через модный Windows Admin Center.
Журналы которые нас будут интересовать находятся в таких расположениях:
- Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
- Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
- Microsoft-Windows-TerminalServices-SessionBroker/Admin
- Microsoft-Windows-TerminalServices-SessionBroker/Operational
- Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational
Строим алгоритм обычного пользователя работающего удаленно. Сотрудник подключается к VPN серверу, после успешного подключения, он запускает клиента удаленного рабочего стола и производит подключение к RDS ферме. Далее сотрудник проходит успешно аутентификацию, его логин и пароль принимается брокерами RDS, далее идет процесс подключения, который заканчивается представленной выше ошибкой.
Первое, что мне бросилось в глаза, это предупреждение с кодом ID 101:
ID 101 RemoteDesktopServices-RdpCoreTS: The network characteristics detection function has been disabled because of Reason Code: 2(Server Configuration).
Далее было такое предупреждение:
Событие с кодом ID 226: RDP_UDPLOSSY: An error was encountered when transitioning from UdpLossyStateSynRecv in response to UdpEventErrorHandshakeTO (error code 0x80040004).
Далее нужно посмотреть, как RDCB брокеры взаимодействовали с сессией пользователя. В журнале «Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational» я обнаружил событие с кодом ID 1149, в котором я вижу, что определенный пользователь был успешно аутентифицирован на RDS ферме, он получил некий IP адрес.
Remote Desktop Services: User authentication succeeded: User: vpn_user Domain: Root.PYATILISTNIK.ORG Source Network Address: 10.10.31.47
Далее я стал изучать информацию из журнала «Microsoft-Windows-TerminalServices-SessionBroker/Operational». Тут я так же обнаружил, что брокер успешно ответил и отправил пользователя на определенный RDSH хост. Тут есть событие с кодом ID 787.
Событие с кодом ID 787: Session for user ROOT\vpn_user successfully added to RD Connection Broker’s database. Target Name = term01.root.pyatilistnik.org Session ID = 18 Farm Name = TermRoot
За ним я видел событие с кодом ID 801, которое имело вот такое сообщение:
RD Connection Broker successfully processed the connection request for user ROOT\vpn_user. Redirection info: Target Name = TERM01 Target IP Address = 10.10.31.47 Target Netbios = TERM01 Target FQDN = term01.root.pyatilistnik.org Disconnected Session Found = 0x0
тут видно, что брокер даже смог обнаружить предыдущую сессию на данном терминале, о чем говорит строка Disconnected Session Found = 0x0
И вы увидите событие с кодом ID 800:
RD Connection Broker received connection request for user ROOT\vpn-user. Hints in the RDP file (TSV URL) = tsv://MS Terminal Services Plugin.1.TermRoot Initial Application = NULL Call came from Redirector Server = TERMRDCB.root.pyatilistnik.org Redirector is configured as Virtual machine redirector
тут видно, что определенный брокер успешно направил пользователя на определенную коллекцию.
Далее переходим в журнал «Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational» тут будет два события,об успешном общении RDS брокера и клиента.
Событие с кодом ID 1307: Remote Desktop Connection Broker Client successfully redirected the user ROOT\vpn-user to the endpoint term01.root.pyatilistnik.org. Ip Address of the end point = 10.10.31.47
Remote Desktop Connection Broker Client received request for redirection. User : ROOT\vpn-user RDP Client Version : 5
Исходя из данной информации я точно вижу, что брокер подключения все успешно обработал и перенаправил пользователя на хост RDSH.
Завершение сеансов непосредственно из программы
Большинство стандартных продуктов фирмы 1С восьмой версии имеют в своем наборе механизм, позволяющий без особого труда удаленно завершить работу пользователя, и обеспечить администратору монопольный доступ к базе. Это обработка «Блокировка соединений с информационной базой».
Найти ее можно по одному из двух адресов:
- В одном из подменю раздела «Сервис»;
- Зайдя в раздел Операции->Обработки.
Рис.2
Внешний вид обработки представлен на Рис.2.
Особенности данной обработки:
- Установка и снятие флажка, и нажатие кнопки «Записать» включает и выключает блокировку пользователей, удаляя сеансы и препятствуя созданию новых подключений;
- Время окончания блокировки не может быть пустым или меньше времени её начала;
- В случае, когда задан параметр «Код разрешения», его можно прописать в строку запуска, для игнорирования блокировки, перед кодом указав «/UC»;
- Если «Код разрешения» не указать, то до истечения срока блокировки попасть в базу будет проблематично (в файловом варианте работы можно попробовать из папки базы удалить файл 1CVcdn);
- Если вместо параметра «/UС» и пароля через пробел указать «/CРазрешитьРаботуПользователей», где С – латинская, можно полностью отключить блокировку для всех пользователей;
- Нажатие кнопки «Активные пользователи, вызывает окно с полным списком пользователей (рис.3), откуда можно открыть «Журнал регистрации» или завершить сеанс каждого конкретного пользователя.
Рис.3
Два вышеизложенных варианта прекрасно работают как в файловом, так и в клиент-серверном режиме. Дальше мы будем рассматривать случаи характерные только для серверной работы.
Управление регистрацией клиентов ICA
Вы можете управлять определять возможность установлений сеансов разрешением
или запрещением регистрации (logon). По умолчанию, при инсталляции MetaFrame
XP регистрации разрешаются. Вы можете запрещать их на время обслуживания или
настройки сервера.
Опции разрешения или запрещения регистрации находятся на закладке MetaFrame
Settings свойств каждого сервера.
- Щелкните правой кнопкой мыши на сервере в левой панели Citrix Management
Console и выберите из контекстного меню Properties. - Для запрещения регистрации, уберите опцию Enable logons to this server
на закладке MetaFrame Settings. - Для разрешения регистрации установите опцию Enable logons to this server.
Управление соединениями
Когда регистрация разрешена, серверы MetaFrame XP по умолчанию не накладывают
ограничения на доступ к серверу или опубликованным приложениям со стороны пользователей.
Пользователи могут создавать несколько соединений и подключаться к любым приложениям,
которые им разрешены.
Отсутствие ограничений хорошо в том случае, когда пользователи хорошо себя
ведут. Все пользователи имеют равные права на доступ к опубликованнм приложениям.
В нерегулируемых условиях вы можете столкнуться с такими проблемами:
- Ошибки, вызываемые пользователями, запускающими одновременно более одного
экземпляра опубликованного приложения - DoS-атаки плохих пользователей, которые запускают множество приложений,
потребляющих ресурсы сервера и лицензии. - Излишнее потребление ресурсов второстепенными приложениями, например, веб-браузерами
На соединения можно наложить два типа ограничений, как показано в таблице:
Тип ограничения | Описание |
Число одновременных соединений | Ограничение количества одновременных соединений ICA, которое пользователь может установить в ферме. См. «» |
Число экземпляров опубликованных приложений | Ограничение общего числа экземпляров опубликованных приложений, которые могут быть одновременно запущены в ферме, а также предотвращение запуска пользователем более одного экземпляра приложения. |
Проверка порта прослушивателя протокола RDP
На локальном компьютере (клиентском) и удаленном компьютере (целевом) прослушиватель протокола RDP должен ожидать передачи данных через порт 3389. Другие приложения не должны использовать этот порт.
Важно!
В точности следуйте инструкциям из этого раздела. Неправильное изменение реестра может вызвать серьезные проблемы. Прежде чем редактировать реестр, создайте резервную копию реестра, чтобы вы могли восстановить его в случае ошибки.
Чтобы проверить или изменить порт протокола RDP, используйте редактор реестра:
Откройте меню Пуск, выберите Выполнить и введите regedt32 в появившемся текстовом поле.
Чтобы подключиться к удаленному компьютеру, в редакторе реестра щелкните Файл и выберите пункт Подключить сетевой реестр.
В диалоговом окне Выбор: «Компьютер» введите имя удаленного компьютера, выберите Проверить имена и нажмите кнопку ОК.
Откройте реестр и перейдите к записи HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\ .
Если PortNumber имеет значение, отличное от 3389, укажите значение 3389.
Важно!
Для управления службами удаленного рабочего стола можно использовать другой порт. Но мы не рекомендуем делать это
В этой статье не описано, как устранять проблемы, связанные с этим типом конфигурации.
Изменив номер порта, перезапустите службу удаленных рабочих столов.
Проверка того, что другое приложение не пытается использовать тот же порт
Для выполнения этой процедуры используйте экземпляр PowerShell с разрешениями администратора. На локальном компьютере также можно использовать командную строку с разрешениями администратора. Но для этой процедуры используется PowerShell, так как одни и те же командлеты выполняются локально и удаленно.
-
Откройте окно PowerShell. Чтобы подключиться к удаленному компьютеру, введите Enter-PSSession -ComputerName <computer name> .
-
Введите следующую команду:
-
Найдите запись для TCP-порта 3389 (или назначенного RDP-порта) с состоянием Ожидает вызова.
Примечание
Идентификатор процесса службы или процесса, использующих этот порт, отобразится в столбце «Идентификатор процесса».
-
Чтобы определить, какое приложение использует порт 3389 (или назначенный порт протокола RDP), введите следующую команду:
-
Найдите запись для номера процесса, связанного с портом (в выходных данных netstat). Службы или процессы, связанные с этим идентификатором процесса, отобразятся в столбце справа.
-
Если порт используется приложением или службой, отличающейся от служб удаленных рабочих столов (TermServ.exe), устранить конфликт можно с помощью одного из следующих методов:
- В настройках такого приложения или службы укажите другой порт (рекомендуется).
- Удалите другое приложение или службу.
- В настройках протокола RDP укажите другой порт, а затем перезапустите службы удаленных рабочих столов (не рекомендуется).
Проверка блокировки порта протокола RDP брандмауэром
С помощью средства psping проверьте, доступен ли затронутый компьютер через порт 3389.
-
Перейдите на другой компьютер, на котором такая проблема не возникает, и скачайте psping отсюда: https://live.sysinternals.com/psping.exe.
-
Откройте окно командной строки с правами администратора, перейдите в каталог, где установлено средство psping, и введите следующую команду:
-
Проверьте выходные данные команды psping на наличие таких результатов:
- Подключение к <computer IP>: удаленный компьютер доступен.
- (0% loss) (0 % потерь): все попытки подключения выполнены успешно.
- The remote computer refused the network connection (Удаленный компьютер отклонил сетевое подключение): удаленный компьютер недоступен.
- (100% loss) (100 % потерь): не удалось выполнить подключение.
-
Запустите psping на нескольких компьютерах, чтобы проверить возможность подключения к затронутому компьютеру.
-
Проверьте, блокирует ли этот компьютер подключения от всех остальных компьютеров, некоторых других компьютеров или только одного компьютера.
-
Рекомендуемые дальнейшие действия:
- Попросите сетевых администраторов проверить, пропускает ли сеть трафик RDP к затронутому компьютеру.
- Проверьте конфигурации всех брандмауэров между исходными компьютерами и затронутым компьютером (включая брандмауэр Windows на затронутом компьютере). Так вы определите, блокирует ли брандмауэр порт протокола RDP.
4)Теперь нам нужно активировать наш сервер лицензий и установить клиентские лицензии через графический интерфейс диспетчера лицензирования на сервере лицензий.
Я активировал сервер лицензий и установил клиентские лицензии PerUser.
Типы клиентских терминальных лицензий (RDS CAL)
Каждый пользователь или устройство, которое подключается к серверам Remote Desktop Session должно иметь клиентскую лицензию (CAL — client access license). Есть два типа терминальных CAL.На устройство (Per Device CAL) – это постоянный тип лицензии, назначающаяся компьютеру или устройству, которое подключается к RDS серверу более одного раза (при первом подключении устройства ему выдается временная лицензия). Данные лицензии не являются конкурентными, т.е. если у вас 10 лицензий Per Device, то к вашему RDS серверу смогут подключится всего 10 хостов.На пользователя (Per User CAL) – такой тип лицензии позволяет одному пользователю подключаться к серверу RDS с любого количества компьютеров/устройств. Данный тип лицензий привязывается к пользователю Active Directory, но выдается не навсегда, а на определенный период времени (90 дней по-умолчанию).
Давайте настроим наше развертывание для лицензирования. Для этого используется командлет ниже:
PS
Set-RDLicenseConfiguration -LicenseServer MSK01-RDS.5house.win -Mode PerUser -ConnectionBroker MSK01-RDS.5house.win
Самый радикальный способ прерывания сеансов
Ситуация, когда вышеописанные способы не сработали, случается крайне редко. Но в случае ее возникновения есть еще один радикальный способ прервать соединения с базой: физическая перезагрузка сервера.
Безусловно, пользователи, не успевшие закончить работу и сохранить данные, будут крайне возмущены таким беспардонным отношением, однако это быстро и это крайне эффективно.
В Windows 2012 R2 и Windows 8.1 Microsoft вернула функционал
Remote
Desktop
Shadowing
(теневого подключения). Напомним, что режим Shadow (теневой сеанс) – может использовать администратором для просмотра и управления существующей RDP сессией любого пользователя. Этот режим работы поддерживается практически с первых версий терминального сервера Microsoft и неожиданно был убран в Windows Server 2012 (связано с переносом стека rdp из режима ядра в пользовательский режим). Функционал RDS Shadow работает и в следующих версиях ОС: Windows Server 2016 / Windows 10.
Кроме того, у режима теневого подключения RDS Shadow и RDP клиента появился ряд новых интересных возможностей. Полный список параметров RDPклиента mstsc.exe, определяющих возможность удаленного теневого подключения к сессии конечного пользователя:
Mstsc.exe
]
/shadow:ID
– подключится к RDP сессии с указанным ID.
/v:servername
– имяRDP/RDS терминального сервера (если не задано, используется текущий).
/control
– возможность взаимодействия с сеансом пользователя (если не указано, используется режим просмотра сессии пользователя).
/noConsentPrompt
– не запрашивать у пользователя подтверждение на подключение к сессии.
/prompt –
используется для подключения под другими учетными данными. Запрашивается имя и пароль пользователя для подключения к удаленному компьютеру.
Ограничения теневых сеансов RDS в Windows 2012 R2
-
Подключаться к чужим сессиям может только администратор сервера. Делегировать эти права обычным пользователем нельзя
-
RDS
Shadow
не будет работать в сетях на базе рабочих групп
Настройка теневых сеансов между пользователями
Вы можете наблюдать в теневых сеансах сеансы других пользователей. Вы также
можете позволить обычным пользователям устанавливать теневые сеансы и следить
за другими пользователями. Это можно использовать для презентаций, обучения,
совместной работы.
Основные шаги для включения этой возможности заключаются в следующем:
- Создайте политику, с правилом, разрешающим теневые сеансы для пользователей.
- Назначьте политику наблюдаемым пользователям
- Опубликуйте панель Citrix Shadow Taskbar и назначьте ее наблюдающим пользователям.
- Обучите наблюдающих пользователей приемам работы с теневыми сеансами
Создание политик
Допустим, вы хотите создать политику для группы пользователей «Sales»,
которая бы могла наблюдать за менеджером AnthonyR. Причем группа «Sales»
использует теневые сеансы между пользователями для совместной работы над анонасми.
- Создайте новую политику. Назовите ее «“Sales Group Shadowing.”
Пример создания политики - Откройте свойства политики Sales Group Shadowing
- Откройте в левой панели папку Shadowing. Выбрите правило с именем
Configure User Shadowing. - Установите состояние правила, щелкнув Rule Enabled.
- Щлкните Allow shadowing.
Поскольку менеджер может работать с конфиденциальными данными, выберите опцию
Prohibit being shadowed without notification.
Если менеджер не хочет, чтобы остальные продавцы могли использовать его мышь
и клавиатуру, выберите Prohibit remote input when being shadowed. - Выберите в левой панели правило Assign Shadowing Permissions.
- Включите его, выбрав Rule Enabled.
- Щелкните Configure для выбора пользователей, которые могут устанавливать
теневые сеансы для наблюдения за сеансом менеджера. Выберите группу «Sales»
и щелкните Add. Имя группы появится в списке Configured Accounts.
По завершении добавления пользователей щклените ОК. - Добавленные пользователи и группы перечислены в правой панели окна свойств
политики. По умолчанию, теневые сеансы для всех пользователей разрешены. Вы
можете запретить установление теневых сеансов, щелкнув Deny. - Щелкните кнопку OK внизу окна свойств.
После создания политики и настройки правил, вы должны назначить ее наблюдаемым
пользователям.
Назначение политики пользователям
- Выберите политику Sales Group Shadowing и выберите Assign Users.
- Выберите пользователей, чьи сеансы будут наблюдаться. В нашем случае это
менеджер AnthonyR. - Выберите пользователя AnthonyR и щелкните Add. Имя AnthonyR появится
в списке Configured Account. - По завершении щелкните OK.
Для облегчения установления теневых сеансов вы можете опубликовать утилиту Shadow
Taskbar. Подробнее см. в справке к утилите.
Мониторинг производительности
Показатели производительности устанавливаются при инсталляции MetaFrame XP
и доступ к ним осуществляется утилитой Performance Monitor, которая поставляется
с Microsoft Windows NT 4.0, TSE и семейством серверов Windows 2000.
Используя Performance Monitor, вы можете наблюдать следующие показатели:
- Показатели потребления ширины канала и сжатие для сеансов ICA и серверов
MetaFrame XP. - Показатели латентности соединений ICA
Для доступа к показателям:
- Выберите Start > Programs > Administrative Tools > Performance.
- Выберите в дереве System Monitor.
- Щелкните Аdd.
- В диалоге Add Counters щелкните список Performance и выберите
ICA Session.
Показатели производительности расположены в списке под опцией Select counters
from list. - Выберите All Counters, если хотите использовать все доступные показатели
или выберите Select
counters from list и подсветите индивидуальные показатели. - Выберите All Instances, если вы хотите разрешить все экземпляры показателей,
или выберите Select instances from list и подсветите в списке только
необходимые экземпляры.
В Мониторе список эксземпляров содержит все активные сеасны ICA, включая теневые.В случае теневых сеансов вы увидите данные производительности только после
его завершения. - Щелкните Add и затем Close.
Теперь вы можете использовать Performance Monitor для наблюдения и анализа
данных производительности, сообщаемых показателями. Подробнее о Мониторе производительности
смотрите в документации Windows.