Восстановление удаленных элементов O365


Как-то раз получил панический (спасите-помогите) звонок, и начал спасать. Удивился, что спасать можно быстро и аккуратно. Раньше таких годных командлетов не было, а поди ж ты, теперь есть. Удалил пользователь письма из корзины с помощью Soft delete, так мы их не моргнув глазом восстановим.

 

 

 

 

Достаточно передать нужные параметры командлету Restore-RecoverableItems, и всё.

Get-RecoverableItems -Identity dima.razbornov ” | Restore-RecoverableItems

Справка живет тут.

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

Да, забыл добавить ТЗ в статью. Исправляю. Continue reading “Восстановление удаленных элементов O365”

Отправка от имени в О365


У пользователей электропочты довольно часто возникает потребность отправить письмо от другого адреса. Цели как правило, при этом преследуются самые благородные, никаких enlarg’ей.

Итак, задача. Дано. Два домена в О365, a.com и b.com сидели на трубе.

Основной домен (primary) у нас a.com, а пользователю нужно отправить письмо от b.com.  По умолчанию считаем, что пользователь использует Outlook, раз уж мы тут про О365. И как быть?

Решение. Есть нескольку путей, и все некрасивые. Первый лежит на поверхности. Делаем общий ящик, экономя на лицензии, и используем для работы OWA и приватный режим, выдав права на отправку от имени. Жуть полная, но работает. Подходит по условию, если нужно отправлять от одного ящика. Если их больше, можно смело совершать прыжки веры, работать так не получится.

Второй путь не лучше: подключить нужный для отправки адрес по POP или IMAP. Это не наш метод, останавливаться не будем.

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

Есть еще четвертый путь, мои маленькие друзья. Итак, для того, чтобы все заработало еще и в мобильном клиенте, нам понадобиться выполнить следующие шаги:

Берем общий ящик,

задаем ему пароль через MSOL,

подключаем как второй аккаунт в мобильном. Обязательно как второй, иначе не заработает.

Все, задача решена.

 

Что нужно делать в выходной?


Правильно, учиться! Поэтому с вашего позволения оставлю ссылку на курсы тут.

Курс 1 / Microsoft 365
Создание и управление современным сервисом почты в малом и среднем бизнесе
Курс 2 / Microsoft 365
Управление безопасностью в малом и среднем бизнесе
Курс 3 / Microsoft 365
Настройка инструментов совместной работы для малого и среднего бизнеса
Курс 4 / Microsoft 365
Управление развертыванием приложений
Курс 5 / Azure
Создание облачной инфраструктуры
Курс 6 / Azure
Резервное копирование и архивация
Курс 7 / Azure
Создание и управление веб-приложениями

Коротенько, или а ваш Exchange так может?


Мерялся третьего дня тут с господами, у кого спуфинг длиннее. Попутно наступил на житейский кейс: большой человек где-то потерял пароль. Ну или не потерял, не суть. Суть в том, что с его аккаунта негодяи стали отправлять нехорошие письма порядочным людям. Но веселье длилось недолго- после пятого отправленного письма О365 заблокировал отправку писем для этого ящика. Выглядело это так:

 

 

 

 

 

 

 

 

 

 

 

 


 

 

 

550 5.1.8 Access denied, bad outbound sender AS(41000001)
Your message couldn’t be delivered because you weren’t recognized as a valid sender.

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

Вот здесь нужно вписать адрес товарищей, которые будут сразу получать уведомления о подобных происшествиях.

 

 

 

 

 

 

 

 

 

Полезная ссылка

https://docs.microsoft.com/en-us/office365/securitycompliance/removing-a-user-domain-or-ip-address-from-a-block-list-after-sending-spam-email

PF и их лимиты (навеяло музыкой из ФБ)


 

 

 

 

 

 

 

 

 

 

 

 

 

 

Администраторы, прибежав в облако начинают радоваться чисто как дети, и только поставив первую ногу на край неба уже стремятся сбросить с себя все обязанности, какие только есть на земле; все ненужное скучное и неприятное следует решительно отринуть, ибо пусть вкалывают роботы, мы же уже же купили этот ваш офис. Примерно такие мысли, так? Так да не так.

Положим, что вы ознакомились с предыдущей заметкой, и воскликнув “в печку ее”, удалили особо ценные данные из ваших общих папок. Или нерадивый сотрудник удалил и пришел каяться. Надо помогать, но прежде чем помогать, настоятельно рекомендуется к прочтению вот эта заметка, ибо информация про сроки хранения может оказаться весьма ценной.  Очень советую присмотреться к сроку хранения данных что на земле, что в облаке. Чересчур маленькое значение может вылиться в большие неприятности.

Ограничения Public Folders

Музыкальный тред

 

 

 

Снова KEMP


Сидим никого не трогаем, медитируем и пьем чай, а парочка больших ящиков отказывается сотрудничать с нами и принудительно уезжать в теплушке в GULAG в облако.

Ошибки для интересующихся будут выглядеть следующим образом:

21/08/2018 00:16:12 [] Fatal error SourceMailboxAlreadyBeingMovedTransientException has occurred.

Continue reading “Снова KEMP”

Добавка


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

Сталкиваюсь до сих пор, что средний сетевик или другой повелитель DNS проверяет всякое используя nslookup или dig, в зависимости от вероисповедания, и не знает о таких штуках. Хочется поэтому рассказать о них, и побудить читателя ими попользоваться.

Крайне полезны такие сервисы, когда вы определяете жалобы пользователей на скорость работы О365. Еще полезней они если вы прогоните такие и подобные тесты до побега в облако, ибо на форумах технета даже в русскоязычном сегменте я с подобными вещами сталкивался, что уж говорить о других, где облака прочно и давно обосновались. Щупаем, привыкаем, используем. На сегодня все. Будьте здоровы.

 

 

 

 

Cправка в О365 всё


Как-то так получилось (это формула успеха, если что), что после громкого поглощения Гитхаба происходят тихие и незаметные события. Например, перестала работать справка в О365. Перестала работать уже месяц, и я, например терпеливо жду пока ее починят, руки все время помнят как быстро посмотреть на ключик или параметр, а справка пока не работает. Вот как-то так.

 

 

Если вам нужна экстренная помощь, то за ней нужно звонить по этим ссылкам:

https://aka.ms/office-powershell

https://docs.microsoft.com/en-us/powershell/module/

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

Ну, и мини опрос, а то читатели будут мне угрожать отписаться и дизлайкнуть:

KEMP и все-все-все


Здравствуй, дорогой читатель. Пишу тебе я сегодня из горящего танка.

 

Поскольку чувство после работы с балансировщиком именно такое.

Первое, на что напоролись при проверке создания MRS точки миграции (хорошая статья по традиции, как она работает под капотом есть тут) была ошибка Test-MigrationServerAvailability. 

Выяснилось, что в шаблонах по умолчанию выключен TLS 1.0, а его очень любит процедура создания конечной точки миграции, и жить без него не может.  А шаблоны очень любят использовать жгучие брюнеты, по бложикам которых админ с бутербродом в руке настраивает крутую железку. Такой вот замкнутый круг.

Включили. Точка создалась, но появилась новая ошибка 501. связанная с RFC-7231 Compliant. Победили и ее.

Еще есть затык с USC, так что надо быть внимательным и осторожным, и конечно, проверять эти вещи до миграции ящиков в облако. Ну и 10 раз подумать, стоит ли использовать балансировку или лучше по практикам лучших собаководов сделать публикацию точки БЕЗ использования балансировщиков, файерволлов, прокси серверов и прочих прекрасных вещей.

По традиции, соцопрос:

 

 

 

Something went wrong…


Предположим, Вы мигрировали ящик пользователя в царство добра О365.

Пользователь становится зачем-то недоволен, так как у него не работает перенаправление или OWA Redirect для его ящика. Ошибку он получает вот такую, а разбираться с ней – вам, конечно.

 

 

 

 

 

 

Если почистить пул на бэкенде почтового сервера где находится активная база данных, то ошибка становится менее туманной, и из-за туч и облаков проступает лучик солнца:

 

 

 

 

То есть уже не просто We could not find a mailbox for this user. А есть продолжение

Continue reading “Something went wrong…”