MSMQ инициировал powershell - срабатывает, но ничего не делает для переадресованного сообщения

Это на Windows Server 2008 R2 Enterprise (64-разрядная версия).

Я хочу выполнить сценарий powershell, когда сообщение поступает в определенную очередь. Это работает, как и ожидалось, если я захожу на сервер и использую утилиту для перемещения/копирования сообщения в очередь.

Правило не имеет условий и является правилом «заглянуть».

Сообщение на самом деле предназначено для отправки с другого сервера. Когда это происходит, появляется сообщение, и, взглянув на диспетчер задач, я вижу, что powershell.exe работает, но сценарий powershell, похоже, не выполняется.

Я попытался упростить это, просто запустив тестовый скрипт для записи в файл в том же каталоге, что и скрипт. Опять же, это работает, если я вручную перемещаю сообщение в очередь, но результаты будут такими же, если сообщение поступает с другого сервера; скрипт, кажется, не выполняется.

Триггер определенно срабатывает, я вижу powershell.exe с ожидаемой командной строкой в ​​диспетчере задач Windows, он просто ничего не делает, если сообщение приходит после отправки с другого сервера.

Для параметров у меня просто есть полный путь к скрипту в качестве строкового параметра для моего тестирования.

Я убедился, что сетевая служба имеет права доступа к очередям и каталогу сценариев.

В журналах событий ошибок нет.

Я пробовал следующее, что не дало разных результатов:

  1. Переключение на 32-битный powershell.exe.
  2. Добавьте условие, которое всегда истинно.
  3. Переключитесь с сетевой службы на учетную запись домена для служб очереди сообщений и триггеров очереди сообщений и добавьте разрешения учетной записи для очередей и каталогов.

Так может кто-нибудь еще придумает что-нибудь попробовать?

Есть ли способ добавить программный переключатель в параметры правила? Он помещает все строковые параметры в кавычки, а выбор exe не позволяет переключаться.

Есть ли способ зафиксировать вывод stderr при выполнении триггера? Вероятно, это как-то терпит неудачу, но я не могу найти способ увидеть это.

Содержимое моего "тестового сценария":

$fileName = "C:\Users\Public\Documents\Scribe\Test\MoveMessage.err";
("tested ok") | Out-File $fileName;

Спасибо!

Изменить:

Я переключился на использование журнала событий записи, и это правильно регистрирует сообщения.

write-eventlog -logname "Windows PowerShell" -source "PowerShell" -eventID 1 -message "TestScript.ps1 Script Started."

Делая это, я обнаружил, что любой скрипт с MessageId в качестве параметра не будет работать, если сообщение было отправлено с другого компьютера. Это происходит, даже если messageId даже не используется в сценарии.

Это может быть связано с тем, что messageId выглядит как «73493861-3988-4109-8356-206a1d7792da\25», но я не уверен, почему это не сработает в зависимости от источника сообщения. Идентификатор сообщения действительно разбивается на 2 аргумента, хотя \xx находится в дополнительном аргументе.


person wysiwyg    schedule 25.09.2015    source источник


Ответы (1)


По-видимому, основная проблема заключается в том, что в некоторых ситуациях нельзя использовать messageId в качестве параметра правила триггера. Вместо этого я использовал lookupId, и все работает так, как ожидалось.

person wysiwyg    schedule 25.09.2015