Назад | Перейти на главную страницу

Пути к профилям пользователей в сеансах RemoteApp

Я пытаюсь настроить ферму служб терминалов, обслуживающую некоторые из наших бизнес-приложений. Основная цель - использовать их в качестве RemoteApps через шлюз служб терминалов для пользователей, находящихся где-то далеко от главного офиса. У меня нет больших проблем с настройкой фермы, веб-сервиса и шлюза. Моя головная боль теперь связана с профилями пользователей.

Представьте, что вы запускаете приложение Excel как RemoteApp из внешней сети. Затем вы нажимаете «Сохранить», и по умолчанию вы получаете путь к документам профиля на TS-сервере. Пользователи не поймут, что он не локальный, сохранят файл и через некоторое время обнаружат, что он «потерян». К сожалению, мы не используем перемещаемые профили в нашей организации, так что это не лучший вариант. Кроме того, сам пользователь внешней сети не получит к ним доступа. Так что единственный способ - использовать локальные профили на машинах пользователей для хранения результатов их работы.

Я пытаюсь заставить его работать - GPO делает пару вещей - он выполняет простые команды:

net use x: \\tsclient\c
md x:\ts_remote

Я использую путь x: \ ts_remote, потому что пользователя с именем «John_Woo» в нашей корпоративной сети можно назвать просто «Пользователь» на его частном локальном компьютере, а не в домене, поэтому я не могу использовать C: \ Documents пользователя по умолчанию. и Настройки \% username%. Затем запускаю небольшой скрипт:

Dim WSHShell
Set WSHShell = CreateObject("WScript.Shell")
WSHShell.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Personal", "X:\ts_remote"
WSHShell.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\My Pictures", "X:\ts_remote"
WSHShell.RegWrite "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders\Desktop", "X:\ts_remote"

Хотя это как-то работает, мне очень не нравится моя установка. Первая большая проблема заключается в том, что X: disk (пользовательский C :) иногда вообще не отображается по каким-то странным причинам. Или он отображается, но находится в каком-то «оффлайн» состоянии и активируется только при нажатии на него. Второе - отображение X: иногда работает крайне медленно! Я имею в виду очень плохую производительность, может потребоваться 15-20 секунд, чтобы открыть диалоговое окно «Сохранить», а затем примерно в два раза дольше, чтобы действительно сохранить пустую электронную таблицу Excel.

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

Я не удивлен, что у вас возникли проблемы с отображением общих ресурсов на клиенте. Соединения WAN кажутся быстрыми вплоть до того момента, когда вы пропускаете через них трафик SMB, а затем они замедляются до обхода.

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

У меня нет действительно хорошего ответа на эту проблему, за исключением обучения пользователей, а это один из стандартных оксюморонов ИТ. Не могли бы вы использовать какой-либо другой механизм для пользователей, чтобы получить доступ к файлам, хранящимся на офисных серверах? Возможно, веб-интерфейс или rsync?

JR

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

Несколько раз за свою карьеру я сталкивался с совершенно неоптимальными решениями, которые предлагались, потому что «они просто хотят, чтобы это работало» (как вы выразились в своем комментарии Джону Ренни). Есть попытки соответствовать требованиям и ожиданиям пользователей, а затем - против ветряных мельниц. Если бы руководство попросило вас повернуть время вспять или превысить скорость света, вы бы посмеялись над ними. Если вы не собираетесь писать код для решения своей проблемы, попытка «изменить правила» того, как работает существующий программный продукт, очень похожа на попытку переписать законы физики. Могут быть некоторые хаки, которые «вроде» работают, но в основном программное обеспечение работает так, как будто оно предназначено для работы.

Непостоянная производительность, которую вы видите, объясняется тем, что вы пытаетесь использовать функцию таким образом, чтобы она не была предназначена для использования, а также потому, что временная сетевая "погода" между клиентским компьютером и серверным компьютером влияет на скорость передачи и задержку. . Я не могу себе представить, что расширение протокола «сопоставление клиентского диска» для RDP действительно прощает изворотливое сетевое подключение.

На мой взгляд, вам нужны «перемещаемые профили пользователей служб терминалов» (см. Вкладку «Службы терминалов» в свойствах пользователя Active Directory). Если вам нужно, чтобы эти файлы были доступны для приложений, работающих локально на клиентских компьютерах, вам необходимо предоставить эти файлы клиентам либо через VPN, либо через что-то вроде WebDAV через SSL.

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