Что удивительно, в мобильном клиенте Outlook, обнаружил несколько копий злосчастной папки и писем в исходном ящике, все удалил, но результат не улучшился.
С докой пока не разбирался, пока использовал костыльное решение:
Т.к. целевой ящик предназначен для системы заявок OTRS, в системе настроил в Фильтре PostMaster
Правило
Таким образом исключив спам заявок "One or more of the folders in your mailbox are named incorrectly."
Понимаю, что такой костыль может засесть надолго, и имеет все шансы быть забытым, но спам в системе заявок каждые 3 минуты, это лишняя трата времени сотрудников разбирающих заявки.
Также, прошелся командлетом Get-MailboxFolderStatistics
В исходном ящике, нет вхождений по некорректному имени папки/письма "Тест копирования/перемещения письма"
В целевом же ящике обнаружил несколько вхождений по названию папки.
Однако, эти вхождения не удается выявить утилитой MFCMAPI
Чтож, продолжаю копать дальше.
Если вдруг кому известен способ освободить доброго друга mailbox assistant, от бесполезной задачи поиска такого кривого письма, буду весьма благодарен.
Роман Безруков, с помощью утилиты увидел несколько вхождений злосчастного письма, удалил их, почистил папку "Удаленные", удалил пользовательский OST файл.
Но результат не изменен, письма поступают ровно также.
Не сумел разобраться с поиском в утилите MFCMAPI, возможно нужно поискать поглубже с помощью данной тулзы.
Роман Безруков, да, использовал тот же командлет: Get-Mailbox -ResultSize unlimited | Search-Mailbox -SearchQuery 'subject:"Тест копирования/перемещения письма"' -DeleteContent -Force | where {$_.ResultItemsCount -gt 0} | ft DisplayName, Success, ResultItemsCount, ResultItemsSize
Pavel Horoshilov, с машины 172.16.254.101 трассировка проходит, как и пинг:
Трассировка к [10.0.1.1]
Трассировка маршрута к AIRPORT-TIME-CA [10.0.1.1]
с максимальным числом прыжков 30:
1 4 ms <1 мс 4 ms AIRPORT-TIME-CA [10.0.1.1]
Трассировка завершена.
Ping узла [10.0.1.1]
Обмен пакетами с 10.0.1.1 по с 32 байтами данных:
Ответ от 10.0.1.1: число байт=32 время=1мс TTL=255
Ответ от 10.0.1.1: число байт=32 время=1мс TTL=255
Ответ от 10.0.1.1: число байт=32 время=3мс TTL=255
Ответ от 10.0.1.1: число байт=32 время=1мс TTL=255
Pavel Horoshilov, т.к. ПК 172.16.254.101 непосредственно находится в сети роутера 10.0.0.1, трассировка должна быть, по факту смогу проверить уже завтра в рабочее время, т.к. оборудование выключено.
ValdikSS, так я бы не против чтоб маршруты затягивались из OpenVPN.
Кстати, при добавлении маршрута на сервер 1С:
#route -p add 10.0.1.0 mask 255.255.255.0 172.16.254.101 metric 1 if 17
Начало трассировки обнадеживает, но дальше что-то идёт не так...
Трассировка маршрута к 10.0.1.1 с сервера 172.16.254.132
Трассировка маршрута к 10.0.1.1 с максимальным числом прыжков 30
1 10 ms * 6 ms ADMIN-ПК [172.16.254.101]
2 * * * Превышен интервал ожидания для запроса.
3 * * * Превышен интервал ожидания для запроса.
4 * * * Превышен интервал ожидания для запроса.
Что же, изменение команды ни к чему не привело.
Но включив маршрутизацию пакетов на машине 172.16.254.101, пакеты стали сразу теряться на первом же хопе.
Pavel Horoshilov, но 172.16.254.1 не знает маршрута к 10.0.1.1, 10.0.1.1 находится же за 172.16.254.101, относительно 172.16.254.132
Попробую изменить команду на:
# route -p add 10.0.1.0 mask 255.255.255.0 172.16.254.101 metric 1 if 17
Так ну нет же, они смотрят портами WAN в мир, все VPN соединения выполнены через сервер OpenVPN (172.16.254.1)
Синие стрелочки на схеме всенаправленные, просто так получилось нарисовать.
С докой пока не разбирался, пока использовал костыльное решение:
Т.к. целевой ящик предназначен для системы заявок OTRS, в системе настроил в Фильтре PostMaster
Таким образом исключив спам заявок "One or more of the folders in your mailbox are named incorrectly."
Понимаю, что такой костыль может засесть надолго, и имеет все шансы быть забытым, но спам в системе заявок каждые 3 минуты, это лишняя трата времени сотрудников разбирающих заявки.
Также, прошелся командлетом Get-MailboxFolderStatistics
В исходном ящике, нет вхождений по некорректному имени папки/письма "Тест копирования/перемещения письма"
В целевом же ящике обнаружил несколько вхождений по названию папки.
Однако, эти вхождения не удается выявить утилитой MFCMAPI
Чтож, продолжаю копать дальше.
Если вдруг кому известен способ освободить доброго друга mailbox assistant, от бесполезной задачи поиска такого кривого письма, буду весьма благодарен.