Удаленные элементы


и не только. Если облачному парню прилетит задача восстановить что-то, то здесь самое время остановиться на минуту и призадуматься: старые добрые способы загрузки в PST не работают, тут вам не локальный сервер с расшаренной папочкой. Что же делать? Выход есть!

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

Сегодня  вашему вниманию предлагаю две темы: как восстановить удаленные элементы из ящика пользователя, и как восстановить удаленную общую папку, которою Вы затащили в облако. Кстати, не могу не отметить тонкий момент. [ТЗ моде он ] Сейчас на правах гибрида ящик пользователя можно вернуть домой в три клика. А вот общие папки пока такого механизма не имеют, и не понятно, будут ли иметь: про такие планы свечной заводик пока не сообщал.

Ссылки для самостоятельного ознакомления:

https://blogs.technet.microsoft.com/recoverableitemscmdlet/2018/01/08/45

https://blogs.technet.microsoft.com/exchange/2015/10/09/introducing-public-folder-lost-and-found-functionality/

https://blogs.technet.microsoft.com/exovoice/2016/11/23/public-folders-data-recovery-scenarios/

Реклама

Не отправляются письма на почтовые ящики хостинга outlook.com


Уже писал о подобной штуке в О365.

Пользователь AM5EUR02FT061.mail.protection.outlook.com отклонил ваше сообщение на следующие адреса электронной почты:

%любой адрес почтового ящика на хостинге outlook.com%

AM5EUR02FT061.mail.protection.outlook.com выдал это сообщение об ошибке: Access denied, banned sender[1.23.*.*]. To request removal from this list please forward this message to delist@messaging.microsoft.com. For more information please go to http://go.microsoft.com/fwlink/?LinkId=526653. AS(508)

Диагностические сведения для администраторов:

AM5EUR02FT061.mail.protection.outlook.com
Remote Server returned ‘550 5.7.511 Access denied, banned sender[136.243.*.*]. To request removal from this list please forward this message to delist@messaging.microsoft.com. For more information please go to %ссылка%. AS(508)’

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

Service Unavailable — DNS failure

The server is temporarily unable to service your request. Please try again later.

Reference #11.8e9b7b5c.1518792197.152942fc

Но в тайном месте нашлась еще одна ссылка для разблокировки. Я понимаю, что сервис не столь популярный, но если наткнетесь на проблему с разблокировкой будет очень полезно. Пользуемся ссылкой

https://postmaster.live.com/snds/ 

 

 

2018. Что поменялось?


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

Что изменилось с  конца 16 года?. Да почти ничего. Добавился новый план F1 (все планы быстро можно сравнить вот тут), который стоит 4$ в месяц. Включает, что характерно не только почту, которую все сравнивают, но и скайпы и вандрайвы.  Здесь нужно четко определиться. Что сравниваем? Голую почту? Тогда один пакет лицензий. Почта плюс СФБ? Другой. Терабайтные (хотя что стесняться, Onedrive до 5 ТБ предлагает для пользователя, нужны ли тогда полки для файлопомоек?) Вопрос всегда в том, что и как считать, чтобы не опускаться до магии цифр.

Т.е. если взять счеты, то возьмем 500 абстрактных сотрудников на 4 доллара в месяц по плану F1 (не берем скидки, выжатые вами из добрых менеджеров по продажам), получаем:

500 чел. *4 =2000 USD. * 12 мес.= 24.000 USD Total за один календарный год. На сегодня по курсу Мосбиржи это 1 350 000 р. 00 коп.

Восемь лет жизни системы будут стоить 10 мульенов. Как-то так, все без обману. А теперь следите за руками: дорого?

В табличке плана хорошо видно, что мы получаем. Остается дело за малым — посчитать  и сравнить стоимость сервиса  у себя на площадке (и тут, конечно, надо зажмуриться и сказать что считать будем целых два сервера стандарт, назовем это все Дагом, купим еще Вим с лентой и это все у нас будет противостоять светлому и чистому прогрессу, называемому облако О365).

Погружаться в опасные дебри антиспама, балансировщиков, публикации, сервисов OTP (и других из коробки), столь удобных для пользователя, и прочее не будем. Это усложнит нашу простую и незамутненную конфигурацию из двух серверов, поэтому я предложу читателю такие упражнения факультативным заданием. Кому-то нужны одноразовые пароли, а кто-то перебьется и лучше купит самосвал песка: он нагляднее, роднее и сразу понятно, какого качества сервис, хорошего или не очень. Песок же можно потрогать, он чистый и мягкий.

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

Забыл запилить соцопрос, исправляюсь.

 

Кто не пьет и не курит, и


на праздники дежурит?

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

Итак:

Интересный мультик про Azure SR. Наверное, это самое бодрое из того, что есть по теме: смотрел еще, все было хуже.

О365

O365

Exchange storage — если Вы не уверены как там все это: транзакции, логи, уменьшается ли база, или ее надо дефрагментировать для этого, или не надо, сомневаетесь во всяком, как Евгений год назад, то это видео посмотрите обязательно. И если не сомневаетесь- тоже, толково рассказано и очень годно. Вспомню если еще что-то, подкину ссылку. Всех с наступающим!

Пять минут, пять минут…


так сколько это все-таки, много или мало?

Посмотрел в черновик — лежит заметка два года уже, я про нее забыл. Надо в черновики ходить чаще, а не размениваться на хайп 🙂 Буду работать над собой, хотя это и не просто.

Заметка была про то, много пять минут это или мало.

Я еще два года назад  (или даже больше) честно, четыре года, оказывается как-то пару раз сталкивался и кому-то на форумах даже разжевывал, но все потонуло. Вроде как ресурс блога ну очень известный, да и автор не кто-то там, а Ned Pyle, вот и думаешь, что все вокруг про это знают. Ан нет.

Спросишь кого встречного — будут кричать, что разница во времени в домене критична, и все взорвется. Вот прям туши свет. Сильная разница действительно критична (вот еще одна заметка на эту тему, о ней как-нибудь в другой раз, раз уж пошла мода выкапывать годноту 5-летней выдержки), это уж точно не секрет Полишинеля. Но поскольку с 2000 года нам постоянно на курсах, лекциях, старшие товарищи на партсобраниях и много где еще повторяют, что нет, нет, нельзя- все и как-то пребывают в уверенности что нельзя. И многие на интервью даже спрашивают друг друга об этом. И тоже думают, что нельзя. Но с сегодняшнего дня даже последнему вовнею должно быть известно, что можно.

Итак, если время в у клиента убежало на 5 минут и более, то сервер ему пришлет метку коррекции в ответе, и ничего страшного не случится!

If the server clock and the client clock are off by more than the policy-determined clock skew limit (usually 5 minutes), the server MUST return a KRB_AP_ERR_SKEW. The optional client’s time in the KRB-ERROR SHOULD be filled out.

Статья-первоисточник, собственно здесь.

Первопричина, ставшая поводом к заметке, здесь.

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

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

TLS 1.2 Вы готовы?


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

https://blogs.technet.microsoft.com/askpfeplat/2017/11/13/demystifying-schannel/

https://blogs.technet.microsoft.com/askpfeplat/2017/12/26/cipher-suite-breakdown/

Не могу не отметить, что качество информационных статей такого рода чрезвычайно высокое, а самих их крайне мало. Из последнего вспоминается разве что похожая вещь про RDP,

про которую недавно настрочил Илья.

Ну и рядом музыкой навеяло вот это:

To provide best-in-class encryption, and to ensure our service is more secure by default, we are moving all of our online services to Transport Layer Security (TLS) 1.2+. As a result, we will be removing support for TLS versions less than 1.2 from our online services, beginning March 1, 2018.
How does this affect me?
Starting on March 1, 2018, all client-server and browser-server combinations must use TLS 1.2 or later protocol versions to be able to connect without issues to Office 365 services. This may require certain client-server and browser-server combinations to be updated. Although current analysis of connections to Microsoft Online services shows that very few customers still use TLS 1.0 and 1.1, we are providing notice of this change so that you can update any affected clients or servers as necessary before support for TLS 1.0 and 1.1 is disabled. If you are using any on-premises infrastructure for hybrid scenarios or Active Directory Federation Services, make sure that these infrastructures can support both inbound and outbound connections that use TLS 1.2.
What do I need to do to prepare for this change?
We recommend you proactively address weak TLS usage by removing TLS 1.0/1.1 dependencies in your environments and disabling TLS 1.0/1.1 at the operating system level where possible. Begin planning your migration to TLS 1.2+, today.
Вспомнил еще один не имеющих аналогов труд по теме, перекликается с первым ответом из опроса.
Ну и по традиции, мини опрос: