Удаленное приложение RemoteApp "забывает" пароль пользователя
 

Прошу помощи уважаемых форумчан. Я лишь в начале пути изучения серверных технологий, только начал осваивать w2k8 R2 Standart.
Сейчас необходимо оперативно запустить один проект, сроки, как обычно, поджимают, а тут образовалась некоторая проблема, в решении которой и прошу помощи.

На сервере W2k8 R2 подняты следующие роли:
DHCP-сервер
DNS-сервер
Доменные службы Active Directory
Сервер печати и документов
Службы удаленных рабочих столов (Установлены лицензии "на устройство")
Файловые службы

В диспетчере удалённых приложений RemoteApp, в списке Удалённые приложения RemoteApp добавлена одна-единственная программа, с которой должны работать пользователи домена. Так вот, если на удалённом ПК войти в домен с учёткой имеющей членство в группе администраторы, то требуемая программа запускается и работает отлично. НО! Если на удалённом ПК войти в домен с учёткой обычного юзера (того, который и должен работать с этой программой), то при запуске rdp-файла, комп некоторое время думает, пытаясь запустить прогу, затем попытки запуска прекращаются и становится доступной кнопка "сведения", при нажатии на которую открывается удалённый рабочий стол с красным крестиком и сообщением "неверное имя пользователя или пароль" и кнопка ОК. Нажимаем ОК, попадаем на логонскрин удаленного компа. Там можно либо сменить пользователя, либо ввести пароль к текущему пользователю. Ввожу действующий пасс учётки юзера домена, вуаля - прога запускается, работает, всё красиво. Можно прогу закрыть (удалённый сеанс, соответственно, закрывается), а через некоторое время снова запустить - никаких проблем с паролем не возникает, прога стартует без вопросов. НО! Если между закрытием и последующим запуском прошло где-то более получаса или, тем более, была перезагрузка ПК - снова возникает проблема с паролем...

Об rdp-файле.
Файл создал в диспетчере удалённых приложений RemoteApp, затем распространил на клиентские ПК.

О юзере - входит в группу "Пользователи удалённого рабочего стола", "Пользователи домена".

Куда копать не знаю, перечитал кучу доков, мозг уже взрывается, а сроки жмут.
Буду благодарен за любую помощь, совет, ссылку и прочее.
Выручайте:)

Ни у кого даже предположений нет?

Клиентские компьютеры по управлением какой ОС? Если ХР, то предлагаю для начала проверить наличие .net 3.5 sp1 и терминальный клиент 6.1 на них.

Я тоже так думаю, поскольку, RDP файл удаленных рабочих столов создается стандартно и никаких пользовательских данных туда не вносится, а все параметры юзеров пишутся непосредственно на клиентских ПК(логин, пароль), то вероятно ошибка в Net или RDP . ЛИбо еще есть такой коссяк, когда открывается окошко ввода пароля логина в RDP , а переключение языка на панели не производится, хотя показано , что переключено на Англ., поэтому вот и не логинится , потому что пасс на рус или на англ.
Других причин не вижу.

Master-ok, спасибо, что откликнулся.
Да, конечно, клиентские машины WinXP Pro sp3 ru, на всё есть лицензии.

Что касается , то при попытке установки получаем:
О, как! :)
Да и потом, с этого же компа, если заходить под админской учёткой - то всё работает, а если под юзерской, то тоже работает, только с танцами с бубном вокруг пароля :(
То есть, вряд ли, дело в клиенте RDP или в .NET

McRae., да это тоже, вряд ли... специально сделал пасс только цыфрами. И, опять же, под админом-то работает без вопросов. Такая вот засада..

..

Может, .NET Framework 4 накатить?

В контекстном меню RDP-файла есть "изменить", проверь там учетную запись, с помощью которой ты пытешься подключиться к серверу. Для каждой учетной записи рабочей станции параметры терминального подключения свои, и по этому зайдя под пользователем админа у тебя все работает, т.к. там все верно прописано. Используя же учетку юзера, ты сохранил настройки RDP со старым (неверным) паролем. А когда ты вводишь данные, уже после нажатия кнопки "сведения", то данные в RPD-файле не изменяются и ошибка подключения повторяется.

Master-ok,
если бы всё так...
Мало того "изменить", "удалить" уже нажимал и вводил рег-данные по новой, а песня всё таже..
Загадка, блин...
Может в домене где настройку какую надо поправить?

Попробуй .net Framework обновить. Это на всех рабочих станциях происходит?

Master-ok, завтра попробую .net Framework 4 накатить, посмотрю что будет.

На 2-ух тестовых машинах эта ситуация "работает" стабильно, остальные ПК заведены в домен, но пока не используются (до разрешения проблемы).

Не понятно, почему пароль не запоминает - или уж совсем бы не принимал, или работал бы уже. А то ни два, не полтора...

Имеется политика "Всегда запрашивать пароль при подключении" - возможно поможет.

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

Я, к сожалению, отписаться о решении проблемы не могу. Тема давняя, прошёл уже почти год... я тогда много экспериментировал и добил-таки сервер :) После переустановки, такой проблемы больше не возникало. Всё работает отлично.
Так что косяк был не в rdp-клиенте, не в FW, а где-то в глубинах w2k8, на сервере.
Также, вероятно, что с опытом мои руки где-то чуть прямее стали, только не заметил где:)
IVKril, желаю вам удачи!

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

Решил таки я проблему, оказалось баг в венде, открыл кейс в микрософте, ответили, цитирую "Я воспроизвел проблему по Вашему описанию. Невероятно…, но все именно так как Вы описали.", обещали исправить проблему в дальнейшем. Вот описание.
Значит так, не стану описывать нашу топологию всяких доменных политик, связей и наследований. Начну с того как нам быстро развернуть с нуля среду и зафиксировать проблему.
1) Устанавливаем MS Windows 2008R2 standard rus SP1
2) Устанавливаем сетевые настройки для ввода в домен
3) Вводим в домен, предварительно создав в AD организейшн юнит, ВЫКЛЮЧИВ НАСЛЕДОВАНИЕ и навесив на него вновь созданную пустую политику, перед перезагрузкой перемещаем учётку компьютера в этот организейшн юнит и перезагружаемся
4) Устанавливаем во вновь созданной политике два параметра, и заполняем их любым количеством любого текста:
a. Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности\Интерактивный вход в систему: Заголовок сообщения для пользователей при входе в систему
b. Конфигурация компьютера\Конфигурация Windows\Параметры безопасности\Локальные политики\Параметры безопасности\Интерактивный вход: текст сообщения для пользователей при входе в систему
5) Поднимаем роль «службы удаленных рабочих столов» с единственной установленной службой ролей «узел сеансов удаленных рабочих столов», перезагружаемся
6) Добавляем любое удаленное приложение RemoteApp, хоть пейнт
7) Формируем для него RDP-файл
8) С помощью этого файла подключаемся, с любой хоть доменной, хоть не доменной рабочей станции, к серверу. Логин и пароль вводим к примеру того же локального администратора или любого другого, кто входит в группу пользователей удаленного рабочего стола на этом сервере, ставим галку «сохранить пароль»
9) Пейнт запустился, в диспетчере учетных данных рабочей станции появилась запись
10) Закрываем пейнт, ждем 20 секунд, пока на сервере наш сеанс не сменил состояние с «активен» на «отключен»
11) Заходим по ярлыку еще раз, логин пароль не запрашиваются, открывается пейнт, смотрим в диспетчер учетных данных рабочей станции, а запись то пропала!
12) Убираем два параметра политики, установленные ранее
13) Делаем на сервере gpupdate /force
14) Повторяем пункты 8-11, запись уже не пропадает в диспетчере учетных данных рабочей станции

правда может уже все исправлено, я давно эту тему порешал, еще в 2011-ом году.

Здравствуйте. Похожая ситуация была. На сервере поменял пароль! После этого ни созданные приложения, ни вновь приготовленные с помощью remoteapp не запускались на удаленном ПК в локальной сети. Потому как они "запомнили" старый пароль. При запуске, когда remoteapp долго соединяется активна только 1 кнопка "свойства". Нажав на нее понимаешь, что введен не верный логин/пароль. Причем на сервер под админской учеткой той же машины на рабочий стол входишь без проблем. Система уже подставляет запомненный новый пароль.
Оказывается надо именно на той машине, где запускаешь - открыть не приложение remoteapp а к примеру программу paint (mspaint.rdp) созданную при помощи remoteapp нажав на контекстное меню. Там будет пункт "изменить". А далее "удалить". Тем самым вы снимете запомненные старые данные. После этого двойным щелчком щелкаете по приложению и система попросит ввести учетные данные и при необходимости "запомнить". Готово. Теперь при следующих подключениях не надо каждый раз вводить учетные данные!
Тоесть смысл в том, что память у remoteapp управления рабочим столом и память приложения созданного при помощи remoteapp — это совершенно "2 разных человека". Просьба не путать.