Тем временем в замке у шефа


 

 

 

 

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

InnerException :
UnknownElements :
UnknownAttributes :
XmlSchemaType :

Timestamp : 8/11/2018 3:40:41 AM
FailureType : MRSProxyConnectionLimitReachedTransientException
FailureHash : 1469
FailureCode : -2146233088
MapiLowLevelError : 0
FailureSide : Source
FailureSideInt : 1
ExceptionTypes : {MRSProxyLimitReached, MRS, MRSTransient, Transient, Exchange}
ExceptionTypesInt : {21, 10, 11, 2, 1}
WorkItem : MakeConnections
Message : The Mailbox Replication Proxy Service can’t process this request because it has reached the maximum number of active MRS connections allowed. Current connections: 100,
Connections limit: 100.
MessageData :
DataContext : ——–

Remote server: https://mail.х.com/EWS/mrsproxy.svc EX2k13х.com (15.0.995.32 ServerCaps:, ProxyCaps:, MailboxCaps:, legacyCaps:017FFFFFCB07FFFF)
——–
AggregateProvider.ForEachWrappedMailbox: Onprem Source Mailbox
——–
Operation: IMailbox.Connect
Operation: [Connect] IMailbox.Connect
OperationSide: Source

at Microsoft.Exchange.MailboxReplicationService.MailboxCopierBase.<>c__DisplayClass339_0.<CopyMessageBatchInternal>b__0(MessageRec[] subBatch)
at Microsoft.Exchange.MailboxReplicationService.MailboxCopierBase.CopyMessageBatchInternal(List`1 batch, MailboxChanges mailboxChanges, Int32 batchSize,
MailboxUpdates mailboxUpdates, Int32& newMessages, Int32& changed, Int32& itemsCopied, ExDateTime& dtLastMessage)
at Microsoft.Exchange.MailboxReplicationService.MailboxCopierBase.CopyMessageBatch(List`1 batch, MailboxChanges mailboxChanges)
at Microsoft.Exchange.MailboxReplicationService.MoveBaseJob.WriteFolderMessages(MailboxCopierBase mailboxToWriteMessages, FolderStateSnapshot fss, Queue`1 writeQueue)
at Microsoft.Exchange.MailboxReplicationService.Job.<>c__DisplayClass35_0.<ExecuteWorkItemCallback>b__0()
at Microsoft.Exchange.MailboxReplicationService.ExceptionUtils.ProcessKnownExceptionsWithoutTracing(Action actionDelegate, ProcessExceptionDelegate processException)
InnerException : DataExportTimeoutTransientException: The data export was cancelled due to a timeout. The destination didn’t respond in time.
UnknownElements :
UnknownAttributes :
XmlSchemaType :

Timestamp : 8/11/2018 4:07:08 AM
FailureType : DataExportTransientException
FailureHash : c95b
FailureCode : -2147467259
MapiLowLevelError : 0
FailureSide : Source
FailureSideInt : 1
ExceptionTypes : {Exchange, Transient, Mapi, DataProviderTransient, MRSRemote}
ExceptionTypesInt : {1, 2, 30, 101, 20}
WorkItem : WriteFolderMessages
Message : MapiFxProxyTransientException: The data export was cancelled due to a timeout. The destination didn’t respond in time. –> The data export was cancelled due to a
timeout. The destination didn’t respond in time.
MessageData :
DataContext : ——–
——–
Operation: LocalSourceMailbox.CopyMessageBatch

ExceptionTypesInt : {2, 1}
WorkItem : WriteFolderMessages
Message : The call to ‘https://mail.х.com/EWS/mrsproxy.svc EX2k13O.х.com (15.0.995.32 ServerCaps:, ProxyCaps:, MailboxCaps:, legacyCaps:017FFFFFCB07FFFF)’ timed out.
Error details: The request channel timed out while waiting for a reply after 00:00:00. Increase the timeout value passed to the call to Request or increase the
SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout. –> The request operation did not complete within the
allotted timeout of 00:00:50. The time allotted to this operation may have been a portion of a longer timeout. –> The request channel timed out while waiting for a
reply after 00:00:00. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may
have been a portion of a longer timeout. –> The request operation did not complete within the allotted timeout of 00:00:50. The time allotted to this operation may
have been a portion of a longer timeout.
MessageData :
DataContext : ——–
Operation: IMailbox.ExportMessages
Operation: IMailbox.ExportMessages
OperationSide: Source
cuhaci.onmicrosoft.com\75a4e52e-d5d0-405f-a682-c7f725326041 (Primary)
Flags: None
PropTags: (null)
——–
>>>> Scheduled WorkItems: CheckTriggerRecoveryActions(P:0,R:0,S:0,C:0); MakeConnections(P:0,R:0,S:0,C:6859); StartMove(P:0,R:0,S:0,C:4047);
InitializeCopyMessageStatistics(P:0,R:0,S:0,C:125474); EnumerateFolders(P:0,R:0,S:0,C:0); EnumerateFolderMessages(P:0,R:0,S:0,C:93,Cnt=11);
WriteFolderMessages(P:156,R:0,S:0,C:19235); EnumerateFolderMessages(P:19797,R:0,S:0,C:2500); WriteFolderMessages(P:562,R:0,S:0,C:14344);

Не спешите бросаться изменять параметры MsExchangeMailboxReplication.exe.config  если столкнетесь, впереди у нас еще ошибки! Да и изменение настроек ничего не даст.

Первая, которая не лежит на поверхности а прикопана поглубже, ‘StalledDueToTarget_MdbAvailability‘. И вторая, которая намного интереснее, StalledDueToTarget_UnknownReason.

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

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

Advertisements

Коротенько, пока


слушаем всем чатом Олдмана

Давно уже страдал от переподключения сессии в ЕХО, и даже стал задаваться вопросом, а чтобы такое сделать, чтобы перестать волноваться и начать жить. Оказалось, есть проект, который на этот вопрос давно дал ответ.

https://gitlab.com/Lieben/assortedFunctions/blob/master/buildResilientExchangeOnlineSession.ps1

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

Анонс вебинара О365


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

Коротенько, или а ваш 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.

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

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

 

 

 

 

 

 

 

 

 

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

Середина месяца


 

 

 

 

 

 

 

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

История с балансировщиками.

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

В этой связи хочется разведать, что там будут докладывать 25-го начальники транспортного цеха. Москалики, пишите комментарии, (как там говорится-то, забыл. А, лайк и репост, вот!) и приходите на мероприятие. Будем посмотреть, как у нас над головой, облачное небо или не очень.

PS. Длиннопост-бонус для тех, у кого суббота, дождь и нечего делать. Совсем не облачная история, но тоже поучительная и в ней присутствуют трудности и опасности. Приятного чтения.

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


 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

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

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

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