Случай из практики -3

Дело №4

Долгое завершение сеанса удаленного рабочего стола(Windows Server 2008R2).

Продолжительное время пользователи жаловались на долгое завершение сеанса удаленного рабочего стола, при выходе из 1С. Сама программа завершалась моментально, но сеанс удаленного рабочего стола оставался открытым еще долгое время (от 2 до 10 минут), после чего завершался.

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

В результате экспериментов и поисков причины был найден виновник: модуль диспетчера печати SplWOW64, который

отвечает за совместимость работы 32-х и 64-х битных приложений связанных с печатью. Если пользователи ничего не печатали- то процесс не загружался в память и сеанс RDP завершался моментально. Если же пользователь распечатывал что либо перед выходом из сеанса- то SplWOW64, настроенный по умолчанию, не завершался вместе с сеансом. Соответственно сеанс дожидался пока SplWOW64 выгрузится из памяти( а это зависело от того как давно пользователь распечатывал документ) и только после этого завершался. Понятно, что по замыслу разработчиков, SplWOW64 не выгружался в целях более быстрой печати 2-й и последующей страницы, но нас интересует быстрый выход. 🙂

Вот пример REG-файла, решаюшего мою проблему (кстати позже нашел в интернете, кучу похожих рецептов, так что я не претендую на авторство)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print]
«SplWOW64TimeOut»=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs]
«SPLWOW64.EXE»=dword:00000000

Дело №5

Роутер Zyxel Keenetik и почта Google.

Продолжительное время в одной компании(клиенте Вашего покорного слуги), были проблемы с переподключением PPoE соединения. Возникали они бессистемно, но одно было ясно- если соединение было установленно, то оно работало. А вот если упало- то переподключение требовало танцев с бубном и присутствия меня у клиента. Это сильно раздражало как меня, так и клиента. Были предприняты следующие меры по диагностике проблемы: перед сервером, который был роутером, был установлен hub(для возможности отловки всех пакетов), в хаб были воткнуты провода от роутера, провайдера и ноутбука с Network Monitor. Диагностика показала то, что я и так знал- когда все шло нормально, то и в  Network Monitor все выглядело номально, когда же соединение не устанавливалось, то роутер отправлял 4 пакета типа PADI в попытках инициализировать соединение и… ничего не получал в ответ. Вполне возможно, это было связанно и с особенностями программного обеспечения или оборудования клиента, но больше всего было подозрений на оборудование провайдера(поскольку на стороне клиента были заменены сервер, программный роутер, сетевые карты, версия ОС). Авто- поднятие подключения реализованное программно(как из программного роутера, так и отдельно) тоже не хотело дружить с провайдером.

Было решено установить для тестов железный роутер, который бы исполнял только одну роль- поднимать PPoE соединение.

Поскольку от цен на нормальные роутеры клиент начинал топать ногами, был приобретен Zyxel Keenetik. После несложной настройки он был установлен и все заработало! Схема подключения была следующая: Провайдер -> Zyxel Keenetik -> Программный роутер.

Радость моя была преждевременной, поскольку появилась другая проблема, менее значимая для меня, но значимая для сотрудников клиента. Перестал нормально работать веб-интерфейс почты gmail и работающая под ней почта tut.by.

Опять таки, проблема была преходящей- то все работало, то не работало.

Я подозревал, что каким- то образом «повреждаются» SSL пакеты, проходящие через Zyxel, поскольку без него проблем не было. Помог вдумчивый разбор всех настроек роутера, вспомнились слова из тех поддержки провайдера- оставляйте все по умолчанию…

Как оказалось достаточно было выставить на роутере MTU равное не величине по умолчанию (1400), а величине которая установлена у провайдера (1490) — чтобы добиться нормальной работы gmail!

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

З.ы. Кстати сказать, пока Zyxel довольно неплохо ведет себя- попробовал скачать торентик в разгар рабочего дня, когда 50 человек сидело в интернете, скорость 4Мбита мне удалось получить…