Цикл статей «Записки системного администратора» или «Случай из практики» в этот раз объяснит особенности укрощения RemoteApp и 1С в дикой природе условиях современного офиса.

Не так давно мне пришлось поработать с такой замечательной функцией Remote Desktop Services как RemoteApp. Любую технологию лучше всего изучать в практическом применении и мне предоставилась такая возможность — я решил сделать работу пользователей в терминале с программой 1C Предприятие более удобной. Сказано – сделано.

У одного из моих клиентов все получилось как нельзя лучше — бухгалтеры были довольны и программа работает быстро и 1С выглядит привычно, как обычное приложение.

У второго же клиента я столкнулся с небольшой проблемой. Я как обычно добавил приложение в RemoteApp manager. Создал с его помощью файл RDP и скопировал этот файл на рабочий стол пользователя. Запустил:

На первый взгляд все заработало, однако после ввода пароля приложение не запустилось, а спустя несколько секунд появилась вот такая вот ошибка:

Из собственного опыта общения c 1C я знал, что источник ошибки с именем BEX это как правило DEP (Data Execution Prevention). Однако, я уже давно создал исключение для всех критичных процессов 1С в диалоговом окне с настройками DEP! Путем логических размышлений я нашел решение проблемы — необходимо было добавить 1cv7.exe файл в исключения DEP еще раз, только в качестве пути к файлу указать не локальный путь, а тот путь который указан при настройки RemoteApp пакета! Примерно вот так:

\\Server\c$\Program Files\1c\bin\1cv7.exe

После чего я увидел желанное окно программы с выбором базы:

На этом дело можно было бы считать закрытым. Однако, при каждом запуске программы сначала появлялось вот такое вот окно:

Windows сообщала мне, что сомневается в надежности запускаемого файла, и предлагала еще раз подумать, прежде чем запускать его. Каких только вариантов я не перепробовал — редактировал Зоны безопасности IE, менял настройки этих зон, добавлял имя сервера в доверенные и локальные узлы, добавлял системную переменную see_mask_nozonechecks, вобщем перепробовал все что мне насоветовал google.

Время поджимало, поэтому я решил отложить решение проблемы на потом. Вечером я решил проверить работу RemoteApp на своем домашнем компьютере. Немного подправив RDP-файл, я запустил приложение и увидел то же самое окно Open File- Security Warning!

На моем домашнем компьютере установлена Windows 7 RU, а окно с ошибкой было на английском языке, кроме того в заголовке thumbnail для ошибки присутствовала подсказка- слово удаленный. т.е. окно ошибки пробрасывалось с сервера ко мне на экран, и причину следовало искать на сервере! Для сравнения я открыл файл скачанный из интернета и у меня появилось уже родное окно предупреждения — на русском языке и оформленное в стиле темы Aero. Разницу вы ведите на этой картинке:

В окошке “моей” Windows присутствует галочка “Всегда спрашивать при открытии этого файла“, сняв которую можно было бы решить проблему, но в окне которое передавалось с сервера- такой возможности не предоставлено — кто я такой что бы управлять безопасностью на сервере? Мои предыдущие изыскания создали для меня видимую сложность решения проблемы- еще с полчаса я самозабвенно баловался с групповыми политиками — теперь уже на сервере, перепробовал все методы, которые пробовал на клиенте.

Однако решение лежало на поверхности. Зайдя на сервере в настройки безопастности IE, в настройках “местной интрасети” я увидел непорядок. Отсутствовали нужные галочки и в доверенных сайтах было пусто(по идее, при включенной галочке Automaticaly detect intranet network добавлять в доверенные сайты ничего не надо, но на практике лучше подстраховаться, что я и сделал), получилось вот так:

После этого у меня все получилось — программа наконец то запустилась без всяких вопросов (кроме вопроса о пароле разумеется)!!!

На этом можно было бы закончить. Однако после долгих мытарств с RemoteApp и вокруг нее, я стал подозрительным и тщательно стал проверять работу приложения. Обнаружилась еще одна проблема — после закрытия программы сессия удаленного рабочего стола оставалась активной на сервере, а затем, примерно по истечении минуты переходила в состояние Disconnected. По задумке разработчиков, такое поведение обеспечивает более быстрые последующие запуски приложения. Однако у меня (возможно из за кармы) получилось не так. В некоторых случаях после перехода сессии в состояние Disconnected, повторно запустить 1С не удавалось, вместо этого окно запуска приложения изображало процесс соединения и темный экран- затем закрывалось, а на сервере завершалась сессия. Последующий запуск приложения был успешным. Возможно такое поведение характерно только для 1С, но я решил поправить групповые политики — дабы не наблюдать в диспетчере задач множество “дохлых” сессий пользователей. Оказывается, есть такая девушка политика:

Запускаем на сервере терминалов gpedit.msc. Нам нужна политика по Set time limit for logoff of RemoteApp sessions, которая находится по адресу

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Session Time Limits\

После обновления групповых политик дело пошло на лад — через минуту после завершения работы с программой сессия выгружалась. Даже программа стала подключаться к активной сессии без проблем, в следствии чего время жизни сессии решено было продлить до 5 минут. Я рассудил так- если человек закрыл программу и за 5 минут не вспомнил, что он забыл сделать что-то важное, то значит и не вспомнит(или не откроет) ее в ближайшее время. Более долгое открытие программы через некоторое время можно вытерпеть (разница примерно 30 секунд)…

Не решенными остались пара потенциальных проблем – возможность пользователя одновременно зайти в 1С через сеанс удаленного рабочего стола и запустив RemoteApp. Но здесь в качестве контролера выступает сама 1С- она просто пишет, что “Каталог пользователя занят” – возможность потери фокуса при появлении нескольких модальных окон, например некоего окна с вопросом, теоретически, как я понял, можно решить эту проблему нажатием некого сочетания клавиш, но саму проблему я генерировать пока не смог. На сегодня все, а завтра наверняка будут что-нибудь интересное. Ведь как мы знаем Windows работает из коробки. Только неплохо было бы в коробку положить сразу и напильник (как это делает Ikea).

Оригинал статьи