none
Отключение переадресации писем в Out-Of-Office через PowerShell RRS feed

  • Вопрос

  • Коллеги, приветствую.

    В MS Outlook, в параметрах Automatic Replies (Out-Of-Office, OOF или Автоответы) можно настроить отсылку автоответов.

    Там же можно настроить пересылку сообщений: Параметры -> Автоответы -> Правила -> Добавить -> Переслать.

    Вопрос заключается в том, как можно через PowerShell отключить функционал отправки копии сообщения, но при этом не отключать отправку автоответов об отсутствии на рабочем месте?

    Через командлет Set-MailboxAutoReplyConfiguration можно настраивать автоответ: включить или отключить, настроить дату начала и завершения, можно настроить текст сообщения, но нельзя указать, требуется ли пересылать копию сообщений.

    Если смотреть правила через командлет Get-InboxRule $identity - то там правило пересылки, созданное через OOF, не появляется и не отображается.

    Также проверили все параметры у почтового ящика, через Get-Mailbox $identity | fl (в том числе и DeliverToMailboxAndForward и другие) - тут тоже пусто, никаких упоминаний про пересылку нет.

    Также были проверены все транспортные правила, через Get-TransportRule и веб-интерфейс. Никаких следов от правил, созданных через OOF.

    Однако, если MS Outlook закрыт и компьютер выключен - правило пересылки, созданное через OOF - работает и копию писем отправляет. Отсюда можно сделать вывод, что правило настроено не локально, а на сервере MS Exchange, и, по идее, его можно каким-то образом отключить через PowerShell.

    Заранее спасибо!



    • Изменено Aleksandr Kanaev 20 октября 2017 г. 11:47 Корректировка
    20 октября 2017 г. 9:21

Ответы

  • Еще раз повторю вопрос - как через PowerShell изменить настройки (включить, отключить, указать другой e-mail адрес) для правил пересылки сообщений на другой e-mail, которые были настроены через GUI в MS Outlook в параметрах Out-Of-Office.

    Транспортные правила, правила в MS Outlook, MailboxAutoReplyConfiguration - не отображают этих данных.

    Никак, поскольку они были заданы с использованием Outlook или OWA.

    Еще раз озвучу свою мысль несколько в иной формулировке.

    То, что администратор делает командлетами или через веб интерфейс, не важно, как, это серверная сторона. (Помните что я сказал, что правил два вида, серверные и пользовательские? Ок.)

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

    Второе, правила пользовательские, которые хранятся (сюрприз) как элементы в ящике пользователя.

    А вот теперь окончательный ответ на Ваш вопрос.

    Простого способа менять их- нет. Потому что обычно нет такой задачи- подключиться к ящику и что-то там ловко менять. А непростой способ есть ,подключаемся к ящику через EWS, и используя его, Powershell, а также имперсонацию меняем все, что пожелаем.

    Я ответил на Ваш вопрос?


    • Изменено Dima RazbornovMVP 20 октября 2017 г. 12:17 исправил опечатку
    • Помечено в качестве ответа Aleksandr Kanaev 20 октября 2017 г. 13:35
    20 октября 2017 г. 12:14

Все ответы

  • Посмотрите транспортные правила (может пересылка у вас выставлена именно там):

    EAC->Mail Flow->Rules 


    20 октября 2017 г. 9:40
  • Нет, к сожалению там тоже нет данных правил.

    Возможно, для Get-TransportRule есть какой-то секретный параметр, который отобразит настройки пересылки, созданные через OOF в MS Outlook? )))

    20 октября 2017 г. 10:02
  • А здесь:

    get-mailbox $identity | select ForwardingAddress, ForwardingSmtpAddress

    20 октября 2017 г. 10:47
  • К сожалению, и здесь тоже нет. Были просмотрены вообще все параметры: get-mailbox $identity | fl
    20 октября 2017 г. 11:14
  • Однако, если MS Outlook закрыт и компьютер выключен - правило пересылки, созданное через OOF - работает и копию писем отправляет. Отсюда можно сделать вывод, что правило настроено не локально, а на сервере MS Exchange, и, по идее, его можно каким-то образом отключить через Powershell.

    Внезапно, правил два.

    Одни серверные, которыми может рулить админ. Включаются (отключаются) через Set-MailboxAutoReplyConfiguration .

    Вторые правила для простых людей, которые таких сложных вещей не знают.

    Они откроют Outlook или OWA и поменяют их там.

    Пользовательские правила видно через Get-InboxRule $identity.

    Точка, добавить больше нечего.

    Проверяйте OWA, раз не видите их в Outlook. В Вашем первом сообщении не улавливаю вопроса, Если вопрос про PS, то рули для него Вы описали выше- только один командлет. Серверный.  

    20 октября 2017 г. 11:46
  • > Внезапно, правил два.

    Правил не два, их может быть больше. Возможные варианты я перечислил в первом посте. Дописал туда уточнения (спасибо Алексею).

    Речь идёт о том, что почти все параметры можно настроить либо со стороны Клиента (MS Outlook), либо со стороны Администратора (PowerShell).

    > Пользовательские правила видно через Get-InboxRule $identity.

    Правило пересылки, созданное в OOF, не отображается в InboxRule. Ни в MS Outlook, ни в PowerShell, ни в OWA. Про это я написал в самом первом посту.

    > Проверяйте OWA, раз не видите их в Outlook.

    > В Вашем первом сообщении не улавливаю вопроса, Если вопрос про PS, то рули для него Вы описали выше- только один командлет. Серверный.  

     При чем тут OWA и Outlook? Я же написал в начале, что нужна команда через PowerShell.
    И также я написал, что командлеты, указанные выше, не содержат нужных настроек.

    Еще раз повторю вопрос - как через PowerShell изменить настройки (включить, отключить, указать другой e-mail адрес) для правил пересылки сообщений на другой e-mail, которые были настроены через GUI в MS Outlook в параметрах Out-Of-Office.

    Транспортные правила, правила в MS Outlook, MailboxAutoReplyConfiguration - не отображают этих данных.

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


    20 октября 2017 г. 12:04
  • Еще раз повторю вопрос - как через PowerShell изменить настройки (включить, отключить, указать другой e-mail адрес) для правил пересылки сообщений на другой e-mail, которые были настроены через GUI в MS Outlook в параметрах Out-Of-Office.

    Транспортные правила, правила в MS Outlook, MailboxAutoReplyConfiguration - не отображают этих данных.

    Никак, поскольку они были заданы с использованием Outlook или OWA.

    Еще раз озвучу свою мысль несколько в иной формулировке.

    То, что администратор делает командлетами или через веб интерфейс, не важно, как, это серверная сторона. (Помните что я сказал, что правил два вида, серверные и пользовательские? Ок.)

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

    Второе, правила пользовательские, которые хранятся (сюрприз) как элементы в ящике пользователя.

    А вот теперь окончательный ответ на Ваш вопрос.

    Простого способа менять их- нет. Потому что обычно нет такой задачи- подключиться к ящику и что-то там ловко менять. А непростой способ есть ,подключаемся к ящику через EWS, и используя его, Powershell, а также имперсонацию меняем все, что пожелаем.

    Я ответил на Ваш вопрос?


    • Изменено Dima RazbornovMVP 20 октября 2017 г. 12:17 исправил опечатку
    • Помечено в качестве ответа Aleksandr Kanaev 20 октября 2017 г. 13:35
    20 октября 2017 г. 12:14
  • Вариант с подключением EWS понятен. Хотя и не понятно, как именно после подключения через EWS поменять параметры через PowerShell. Как минимум не известно, какие командлеты для этого надо использовать.

    > Второе, правила пользовательские, которые хранятся (сюрприз) как элементы в ящике пользователя.

    Это, видимо, единственное возможное объяснение. Ибо через Get-ADUser таких параметров тоже найти не удалось.

    Но не понятно, почему эти параметры нельзя просмотреть ни через Get-MailboxAutoReplyConfiguration ни через Get-InboxRule. Зачем их нужно было прятать в виде "элементов в почтовом ящике", к которым возможен доступ только через EWS.

    Ок, если больше добавить нечего, я помечу последний ответ как ответ.

    Всем спасибо)

    20 октября 2017 г. 13:35
  • Как оказалось, решить задачу очень просто:

    # Получаем список 3-х правил OoF с помощью ключа -IncludeHidden
    Get-InboxRule -Mailbox username -IncludeHidden

    # Смотрим три правила OoF:
    Microsoft.Exchange.OOF.InternalSenders.Global
    Microsoft.Exchange.OOF.AllExternalSenders.Global
    8338677002381737985

    # Нас интересует правило с цифровым названием, копируем цифры и выполняем:
    Remove-InboxRule -Mailbox username -Identity 8338677002381737985

    Задача отключения пересылки сообщений с сохранением Автоответов через PowerShell успешно решена)

    P.S. За подсказку спасибо Виктории Г., гуру MS Exchange)

    Всех с Наступающими праздниками!

    • Предложено в качестве ответа Dima RazbornovMVP 29 декабря 2017 г. 8:03
    29 декабря 2017 г. 7:47
  • Круто.

    А как вы этими скрытыми правилами разжились в ящике-то, есть понимание?

    29 декабря 2017 г. 8:03
  • Добрый день!

    В данном случае задача стояла именно с правилами, созданными в диалоговом окне настройки OOF, штатными средствами, насколько я поняла. По умолчанию такие правила скрыты в выводе get-inboxrule.

    Бывает, хуже, когда правила повреждаются, тогда их можно удалить только с помощью MfcMapi, это уже проблема.

    https://support.microsoft.com/ru-ru/help/924297/how-to-delete-corrupted-and-hidden-rules-from-a-single-mailbox-in-outl

    Таких правил на клиенте не видно совсем, как в выводе командлета, без параметра показа скрытых.

    Из известных мне примеров появления таких правил:
    - некорректное завершение Outlook
    - настроено правило на делегата, который поврежден или не существует

    9 января 2018 г. 8:12
  • Ага, спасибо, именно это и хотелось услышать.

    Значит про EWS я верно предложил ТС решение, на тайные ключики можно надеяться, но от него нам никуда не деться, если их нет. :)

    Всех благ.

    9 января 2018 г. 9:31
  • EWS это наше все. К сожалению, наталкиваясь на ограничения стандартного powershell у многих руки опускаются и складывается мнение, что ничего сделать нельзя...

    Конкретно изменение, а не удаление правил oof, возможно только через ews.
    Вот тут пример есть на удаление (вообще примеров на EWS достаточно большое кол-во)
    https://blogs.technet.microsoft.com/mspfe/2015/07/22/using-exchange-ews-to-delete-corrupt-oof/

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

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

    В данной конкретной ситуации - powershell все же более обоснованное решение. не стоит эта задача написания целого скрипта :-)

    Но EWS пропагандировать нужно, это да.

    10 января 2018 г. 7:35
  • Да, и не только; работа с делегатами и правами,  трюки с поиском, когда хочется странного (скажем копирования чего-то куда-то) и многое другое. Так что я бы сказал по опыту- побольше, чем немного. ;)

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

    Другое дело, что EWS он как фиддлер- советуешь кому-то взять его в руки, тебе тысячу причин найдут для того, лишь бы этого не делать. Ибо неприятно. И очень не хочется. Хотя кому как.

    10 января 2018 г. 7:44