Blog of Khlebalin Dmitriy

(Дорогу осилит идущий…)

Event ID 12014 – Microsoft Exchange could not find a certificate

На минувшей неделе вдруг не с того не с сего на почтовике (в моем текущем случае это Exchange 2010) появилась ошибка:

Event ID 12014 – Microsoft Exchange could not find a certificate

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

Странное явление. По началу, подозрение пало на только что установленный очередной накопительный пакет обновления Exchange.

Но посмотрев на состояние действующего сертификата, эти подозрения не подтвердились.

snap

snap1

Если реально понимаете, что проблема именно в сертификате, то будут актуальны вот эти посты:

http://msexchangeguru.com/2011/06/22/event12014/

или

http://www.expta.com/2010/09/how-to-fix-msexchangetransport-event-id.html

или

http://sslmagazin.com/install-ssl/33-ssl-install-for-microsoft-exchange2010

можно перевыпустить сертификат.

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

Всем хорошей работы!!!

Реклама

27.12.2016 Posted by | ms exchange 2010 | Комментарии к записи Event ID 12014 – Microsoft Exchange could not find a certificate отключены

Exchange 2010 траблешутинг, продолжение.

В результате «жесткого» восстановления нескольких баз мы все же потеряли одну базу 300 Gb. Потеряли не в прямом смысле слова, база вроде подмонтировалась, Outlook подключается, но идет постоянная синхронизация и почта все равно не ходит, а это значит что база реально не рабочая.

Ящики из нее также в другие хранилища никак не перемещаются, вылетая с ошибкой на 10, 15, 30%, в общем беда. Ситуация крайне нервная и щепетильная. Пришлось оперативно найти решение, так как база встала как раз в начале рабочего дня и в ней всего 15 человек с огромными ящиками.

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

  1. Бэкапим почту в уже неработающем Outlook у тех пользователей, кому не повезло оказаться в битой базе (а я оказался одним из таких).

snap1

2. Отмонтируем текущий ящик пользователя на почтовом сервере (все равно он битый и уже не нужен).

snap2

3. Создаем рядом, новое, чистое хранилище.

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

snap3

5. Создаем новый профиль в Outlook (старый пока не удаляем на случай если что-то пойдет не так, его можно просто пока не использовать).

snap4

6. Открываем Outlook, автоматом цепляется новый профиль и чистый ящик который только что создали.

7. Импортируем в чистый ящик все то, что недавно экспортировали.

snap5

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

9. Проделываем эту операцию для всех пользователей находящихся в этом хранилище.

10. Отмонтируем и забываем (удаляем) про битое хранилище навсегда.

11. Почта начинает благополучно работать. Но в таком случае возникнет еще один подводный камень. Из вне почта благополучно приходит, во вне благополучно отправляется, а вот если захотите написать такому пользователю внутри компании, то вернется вот такой «отлуп»:

snap6

Проблема решается следующим образом. После того как созданы все ящики в новом хранилище открываем наш «любимый» PowerShell на почтовике:

Get-OfflineAddressbook | Update-OfflineAddressbook

Get-ClientAccessServer | Update-FileDistributionService

net stop MSExchangeSA

net start MSExchangeSA

12. Отправляем всем пользователям компании инструкцию принудительно обновить адресную книгу:

snap7

И чтоб тех для кого приходит такой отбойник, люди выбирали непосредственно в адресной книге Outlook, а не в кэш Outlook.

Далее продолжаем работать в прежнем режиме….

Всем хорошей работы!!!

11.11.2016 Posted by | ms exchange 2010 | Комментарии к записи Exchange 2010 траблешутинг, продолжение. отключены

Траблешутинг Exchange 2010.

Наши изыскания с траблешутингом Exchange 2010 продолжаются…

Небольшая предыстория….

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

Место на Exchange закончилось, базы отмонтировались и более не стартанули, так как логи были повреждены (об этом я ранее писал).

Далее несколько баз были жестко восстановлены с помощью eseutil /p

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

new-MailboxRepairRequest [-Mailbox <MailboxID> | -Database <DatabaseID>] -CorruptionType <CorruptionType> [-DetectOnly] [-DomainController <FQDN>]

Здесь

· Mailbox или Database – это соответственно почтовый ящик или база данных;

· CorruptionType – вид проверки, которую вы желаете запустить:

o SearchFolder;

o AggregateCounts;

o ProvisionedFolder;

o FolderView.

· DetectOnly – используется, если вы хотите лишь обнаружить ошибки, но не исправлять их;

· DomainController – определяет контроллер домена для обновления данных.

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

New-MailboxRepairRequest -Mailbox <MailboxID> -CorruptionType SearchFolder,AggregateCounts,ProvisionedFolder,FolderView

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

New-MailboxRepairRequest –Database gold1 –CorruptionType AggregateCounts

snap1

команда будет выполняться в фоновом режиме, а вам будет доступен её RequestID. Также в журнале событий Windows появится событие EventID = 10059, которое будет означать запуск сканирования, событие с EventID = 10048 будет означать успешное завершение операции.

Вот например, результат по моему почтовому ящику после проверки:

snap

Такая проверка, позволит исправить некоторые ошибки, например: у вас Outlook показывает, что в папке ВХОДЯЩИЕ есть одно непрочитанное письмо, а на самом деле такого письма нет (если попробуете сделать стандартную операцию, типа: выделить все письма-сделать их непрочитанными и потом снова сделать прочитанными), то в текущей ситуации это не поможет. Это несколько раздражает. Но после исправления базы на «чанге» и потом повторном закрытии- открытии и повторной синхронизации Outlook такие «баги» пропадут.

Всем хорошей работы!!!

09.11.2016 Posted by | ms exchange 2010 | Комментарии к записи Траблешутинг Exchange 2010. отключены