Ежеутренняя ошибка TermService
 

Доброго времени суток, коллеги.

На далёкой площадке провайдера услуг имеется виртуальный терминальный сервер Windows 2003 R2 Std. SP1. На нём навешен XenApp 5, через который пользователи работают с 1С 7.7.
Ежеутренне возникает ошибка:
Источник: TermService
Код(ID): 1041
Системе не удалось перейти в спящий режим (код ошибки: %hs). Спящий режим будет запрещен до перезапуска системы.
Спящий режим действительно отключен, но что заставляет систему с упорством бегемота пытаться заснуть?

Буду благодарен за советы.
Спасибо.

Может, какое-нибудь задание в sheduler создалось с галочкой

alef2474, что за галочка? Кроме того, ни одного задания, совпадающего по времени с ошибкой, которая, кстати, возникает не в одно и то же время.

Галочка про wake но, может быть, она как-то работает инверсно при известной глючности windows 2003 c засыпанием при переходе через ОЗУ в 4Гб. Но, если не в одно время, то версия не проходит.
Интересно, как Вы отключили спящий режим и в принципе он может включаться от запуска rundll32. Может что-то запускает.

Меньше. 1 ГБ.

Дык, powercfg /h off

Angry Demon, сервер случаем к ИБП не подключен USB или COM-кабелем? В панели управления в "Электропитание" - "Сигнализация" и "Схемы управления питанием" ничего интересного нет?

Нет.

Там всё тривиально: схема "Постоянно включен", спящий режим запрещён.

Надо установить слежение с помощью Procmon за запускающимися процессами и найти связь с желанием уходить в спящий режим.
Надо обследовать журнал 1с7.7 на наличие зависающих в базе пользователей или просто устраивать им общий вечерний вылет, отключая службу по расписанию.

Каким боком зависающий в 1С пользователь может инициировать переход в спящий режим??? :o

Какую службу?

Иногда пользователи запускают сеанс дважды и один остается в теневом состоянии, он пытается заснуть.
Если серверная версия, то службу агента. Это стандартные рекомендации 1С по удалению зависших пользователей.
У Вас их гарантированно нет?

Запрещено политиками XenApp. Пользователь ограничен одним сеансом. Будут пытаться - получат сообщение, дескать, уже.

Файловая DBF-ная.

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

Во-первых, точно не зачыпает (XenApp не позволяет, только мониторит период бездействия и позволяет реагировать на это тем или иным образом).
Во-вторых, если клиент пытается вторично кликнуть на иконке приложения, то XenApp (при наличии запрета запуска нескольких экземпляров приложения) даже не запустит приложение.

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