Чтобы запустить некоторые приемочные тесты на моем сервере сборки, мне нужно открыть сеанс авторизованного пользователя ( белый структура тестирования должна иметь «экран» для постоянного тестирования пользовательских интерфейсов WPF). Очевидно, что это хрупкая установка, и она вносит немало трений в наш процесс.
Возможно ли, чтобы служба Windows работала в фоновом режиме, которая затем могла бы «порождать» сеанс, в который она входит как пользователь, выполняет некоторую работу (в данном случае тестирование), а затем выходит из системы? Или, возможно, есть лучший способ справиться с моей ситуацией, чем то, что мы делаем сейчас? Это расстраивает, потому что, например, если приложение в какой-то момент вылетает из строя, появляется диалоговое окно исключения, замораживающее наш сервер сборки. Я подумывал отключить доктора Вастсона, чтобы справиться с этим, но у меня такое чувство, что я иду по пути, чреватому опасностями.
Прежде всего, поможет немного подробнее о вашей среде. Я предполагаю, что это либо Windows 2003, либо Windows 2008 Server.
Если честно, я не специалист в этом плане, но кто пользуется этим ящиком? Если у вас есть права администратора, вы можете использовать psexec (если вы не слышали о нем, это бесплатная утилита Sysinternals). Вы можете запустить процесс в сеансе консоли (то есть с интерактивным рабочим столом, говоря языком psexec). Если вы автоматически входите в систему в поле с правильными настройками реестра, вы можете заставить PsExec сделать это, если настройки безопасности будут прокляты. Ключи реестра включают хранение пароля в виде открытого текста, поэтому я бы заблокировал такую учетную запись.
PsExec выполняет программу в удаленной системе, где удаленно выполняемые консольные приложения выполняются в интерактивном режиме.
Usage: psexec [\\computer[,computer2[,...] | @file][-u user [-p psswd]][-n s][-l][-s|-e][-x][-i [session]][-c [-f|-v]][-w directory][-d][-<priority>][-a n,n,...] cmd [arguments]
. . .
-d Don't wait for process to terminate (non-interactive).
-i Run the program so that it interacts with the desktop of the
Итак, чего бы это ни стоило, я думаю, вы могли бы запустить сеанс, затем иметь запланированный пакетный сценарий задач, который ищет, какой пользователь вошел в систему, а затем выполните следующие действия, которые запускают процесс с заданным сеансом или интерактивным рабочим столом, если вы это сделаете не указывать, и он также не будет ждать завершения процесса. Он просто создаст его.
%SYSTEMDRIVE%\path\to\psexec.exe -i -d C:\path\to\your\app.exe
Теперь, если у вас есть один из продуктов Windows Server, я думаю, вы можете иногда входить в систему с помощью RDP (mstsc.exe), используя console параметр, теперь admin параметр в Windows 2008.
Опять же, это бессвязная болтовня новичка. Я мог бы быть вне базы с этой работой. Кто-нибудь более знающий мог бы помочь.
Весь сценарий «войдите и работайте» - это что-то вроде проблемы с курицей или яйцом.
Я бы начал с AutoHotkey и посмотреть, не смог ли я заставить его автоматизировать элементы пользовательского интерфейса, которыми мне нужно было манипулировать. Во времена w2K у меня была группа машин, на которых мы блокировали наследование GPO, чтобы явно разрешить «не использовать ctrl-alt-del», а затем использовали autoexec.bat для запуска процесса. Если вы дойдете до этого момента, AHK сможет автоматизировать все остальное. В худшем случае вам может потребоваться использовать AHK для автоматизации сеанса VNC, чтобы обойти сложности прямого входа в систему.
Мне не очень нравится стратегия "Сервис". Между сервисами и пользовательским интерфейсом есть ограничения; поле «Разрешить службе взаимодействовать с рабочим столом» намекает на проблемы, которые могут там возникнуть.
Возможно автоматический вход это вариант.
Очевидно, что если это не виртуальная машина, вам нужны средства контроля безопасности физического сервера.
Запустите необходимые службы тестирования как программы запуска для пользователя с автоматическим входом в систему. Если произойдет сбой, перезагрузите компьютер (с помощью сценария взаимодействия с DRAC, iLO, VMware ESX, независимо от того, что он работает поверх), и службы запустятся заново.