Случай из практики — 4

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

Дело №5. О не печатающем принтере.

После решения проблемы с принтером HP 1120 прошло совсем немного времени, и сразу появился еще один интересный случай. В одной организации был приобретен принтер: HP LJ 1217nfw MFP. В целом впечатление от аппарата были только положительные- сетевой принтер\сканер\факс с поддержкой WiFi и возможности установки драйверов пользователями прямо из веб- интерфейса принтера. Все впечатление портила только одна вещь- невозможность печати из сессии удаленного рабочего стола.

Первые попытки диагностики проблемы показали- что принтер корректно пробрасывается в сессию пользователя, но при попытке что- либо напечатать (даже тестовую страницу), честно сообщает что печать не удалась. Я перепробовал все доступные драйверы, подозревая, что как и в прошлом случае мне нужен драйвер с поддержкой XPS. Причем, после установки полноценного драйвера, он услужливо предлагал ссылку «загрузить драйвер с поддержкой XPS», однако по ссылке такого драйвера мне обнаружить не удалось.

В результате нескольких часов плотной работы, мне удалось решить проблему. По совету разработчиков из Microsoft, я изменил поведение Remote Desktop Easy Print. Для этого я отключил политику Use Remote Desktop Easy Print printer driver first, которая находиться по адресу:

Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Printer Redirection\

А также установил на сервер драйверы для принтера(помните прямо как в Windows 2003?). После этого необходимо перезагрузить сервер!

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

Дело №6. Укрощение 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).