none
HELP ! Как восстановить базы EDB ? RRS feed

  • Вопрос

  • Срочно ! Полетел Windows Server 2008R2 с Exchange Server 2013 CU6. В живых остались только 2 базы EDB - основная и архивная. Видимо, придётся заново ставить Exchange Server 2013. Как на новом сервере можно будет эти базы подсунуть ?

    =STAS=

Ответы

Все ответы

  • Процесс расписан тут: https://practical365.com/exchange-server/restore-exchange-server-2013-database-recovery-database/

    Если сервер утерян безвозвратно, а бэкапов нет, то вам лучше устанавливать эксч в режиме восстановления на сервер с таким же именем. см. тут: https://technet.microsoft.com/ru-ru/library/dd876880(v=exchg.150).aspx

     
  • а следы старого Exchange из AD надо затирать в таком случае ?

    =STAS=

  • что, правда так и оставить ?

    =STAS=

  • Срочно ! Полетел Windows Server 2008R2 с Exchange Server 2013 CU6. В живых остались только 2 базы EDB - основная и архивная. Видимо, придётся заново ставить Exchange Server 2013. Как на новом сервере можно будет эти базы подсунуть ?

    =STAS=

    Небольшое дополнение, чисто для ясности. Если базы не оказались случайно в состоянии Clean Shutdown (т.е. Exchange до аварии не был выключен штатным способом, проверяется состояние баз утилитой командной строки Exchange eseutil.exe /mh), то подсовывать надо базы с журналами транзакций (*.log, надеюсь, они тоже в живых остались).

    Слава России!


    • Изменено M.V.V. _ 6 июня 2017 г. 8:55
  • Да вроде шатдаун нормальный был, но на всякий случай неплохо проверить, спасибо. Ещё бы знать, где эти логи находятся :) А дело, собственно в том, что система у меня на RAID-SSD, а базы и большинство логов, которые было возможно, перенесены на RAID-HDD. Поэтому, собственно, и выжили.

    И ещё одну вещь я не понял: там, в руководстве по восстановлению Exchange, написано:

    1. Откройте файл ADSIEDIT.MSC или LDP.EXE.
    2. Перейдите в следующее расположение: CN=ExServerName,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=ExOrg Name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=DomainName,CN=Com"

    а я никак понять не могу, захожу в ADSIEDIT.MSC, но как перейти по этому пути ?


    =STAS=

    • Изменено -STAS- 6 июня 2017 г. 11:04
    6 июня 2017 г. 10:51
  • А вы ставили эксч в другое расположение?

    Подключитесь к контексту именования конфигурация и найдите объект сервера. Например CN=EXCH01,CN=Servers,CN=Exchange Administrative Group (SDF876G78DSGF6),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local

    6 июня 2017 г. 11:20
  • Да, в другое. На С система и туда по-умолчанию  Exchange, а базы данных и логи на D. Потому как С - на маленьких SSD, которые имеют ограниченное количество циклов перезаписи и дорогие, а D - на HDD.

    =STAS=

    6 июня 2017 г. 12:00
  • Да, в другое. На С система и туда по-умолчанию  Exchange, а базы данных и логи на D. Потому как С - на маленьких SSD, которые имеют ограниченное количество циклов перезаписи и дорогие, а D - на HDD.

    =STAS=

    Коллега, читайте внимательнее статью, которую я вам привел. Там речь идет только о каталоге установки эксча, но не о каталогах с базами. Каталог по умолчанию - %programfiles%\Microsoft\Exchange Server\V15

    Например я тоже ставил по дефолту и система у меня на С. Параметр msExchInstallPath у меня содержит значение C:\Program Files\Microsoft\Exchange Server\V15

    6 июня 2017 г. 16:27
  • А юзеры тоже восстановятся или надо будет как-то заводить новых и показывать, где их ящики в базе данных ?

    В общем, получилось восстановить сервер посредством не CU7 - её я так и не нашёл нигде, а с помощью CU16. Повозившись порядком с Prerequesties, сервер-таки установился, но почему-то ничего не запускается - ни shell, ни административный центр.

    Shell пишет:

    ПОДРОБНО: Подключение к MAIL.regcon.local.
    New-PSSession : [mail.regcon.local] Сбой подключения к удаленному серверу mail.regcon.local. Сообщение об ошибке: Клиенту WinRM не удается обработать запрос. Невозможно определить тип содержимого ответа HTTP от компьютера назначения. Тип содержимого не является допустимым или отсутствует. Подробности см. в разделе справки "about_Remote_Troubleshooting".
    строка:1 знак:1
    + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
       gTransportException
        + FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed

    ... а Административный центр пишет:

    Ошибка сервера в приложении '/ecp'.

    Поставщику топологии не удалось найти службу топологии Microsoft Exchange Active Directory на конечной точке "TopologyClientTcpEndpoint (localhost)".

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

    Сведения об исключении: Microsoft.Exchange.Data.Directory.ADTopologyEndpointNotFoundException: Поставщику топологии не удалось найти службу топологии Microsoft Exchange Active Directory на конечной точке "TopologyClientTcpEndpoint (localhost)".

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

    Трассировка стека:
    [ADTopologyEndpointNotFoundException: Поставщику топологии не удалось найти службу топологии Microsoft Exchange Active Directory на конечной точке "TopologyClientTcpEndpoint (localhost)".]
       Microsoft.Exchange.Data.Directory.ServiceTopologyProvider.GetConfigDCInfo(String partitionFqdn, Boolean throwOnFailure) +466
       Microsoft.Exchange.Data.Directory.TopologyProvider.PopulateConfigNamingContexts(String partitionFqdn) +56
       Microsoft.Exchange.Data.Directory.TopologyProvider.GetConfigurationNamingContext(String partitionFqdn) +61
       Microsoft.Exchange.Data.Directory.ADDataSession.GetNamingContext(ADNamingContext adNamingContext) +406
       Microsoft.Exchange.Data.Directory.ADDataSession.GetConnection(String preferredServer, Boolean isWriteOperation, String optionalBaseDN, ADObjectId& rootId, ADScope scope) +164
       Microsoft.Exchange.Data.Directory.ADDataSession.GetReadConnection(String preferredServer, String optionalBaseDN, ADObjectId& rootId, ADRawEntry scopeDeteriminingObject) +153
       Microsoft.Exchange.Data.Directory.ADDataSession.InternalFind(ADObjectId rootId, String optionalBaseDN, ADObjectId readId, QueryScope scope, QueryFilter filter, SortBy sortBy, Int32 maxResults, IEnumerable`1 properties, Boolean includeDeletedObjects) +3354
       Microsoft.Exchange.Data.Directory.SystemConfiguration.<>c__DisplayClass53.<FindServerByFqdn>b__52() +116
       Microsoft.Exchange.Data.Directory.Diagnostics.ADScenarioLog.InvokeWithAPILog(DateTime whenUTC, String name, Guid activityId, String implementation, String caller, Func`1 action, Func`1 getDcFunc) +233
       Microsoft.Exchange.Data.Directory.SystemConfiguration.ADTopologyConfigurationSession.InvokeWithAPILogging(Func`1 action, String memberName) +409
       Microsoft.Exchange.Data.Directory.SystemConfiguration.Server.GetLocalServerClientAccessArray() +103
       Microsoft.Exchange.HttpProxy.Common.PerfCounters.UpdateHttpProxyPerArrayCounters() +11
       Microsoft.Exchange.HttpProxy.ProxyApplication.Application_Start(Object sender, EventArgs e) +262
    
    [HttpException (0x80004005): Поставщику топологии не удалось найти службу топологии Microsoft Exchange Active Directory на конечной точке "TopologyClientTcpEndpoint (localhost)".]
       System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) +540
       System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +186
       System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +172
       System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +402
       System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +343
    
    [HttpException (0x80004005): Поставщику топологии не удалось найти службу топологии Microsoft Exchange Active Directory на конечной точке "TopologyClientTcpEndpoint (localhost)".]
       System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +539
       System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +125
       System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +731
    

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


    =STAS=

    • Изменено -STAS- 7 июня 2017 г. 16:23
    7 июня 2017 г. 16:00
  • Откровенно говоря, то, что вы наплодили кучу тем и пишете то тут, то там, да еще и сбивчиво, ни разу не помогает понять ту ситуацию, что вы у себя устроили.
    Службы ексчендж сейчас запущены, после того, как вы cu16 установили, проверьте?
    Вообще, раз у вас там такое творится, стоило давно параллельно поднять новый сервер и перенести на него ваши базы, потратив на все это пару часов времени вместо нескольких суток.
    А если окажется, что и базы - вовсе не базы и не монтируются, будет еще веселей:)

    MCSAnykey

    7 июня 2017 г. 19:41
  • Да, в другое. На С система и туда по-умолчанию  Exchange, а базы данных и логи на D. Потому как С - на маленьких SSD, которые имеют ограниченное количество циклов перезаписи и дорогие, а D - на HDD.


    =STAS=

    Коллега, читайте внимательнее статью, которую я вам привел. Там речь идет только о каталоге установки эксча, но не о каталогах с базами. Каталог по умолчанию - %programfiles%\Microsoft\Exchange Server\V15

    Например я тоже ставил по дефолту и система у меня на С. Параметр msExchInstallPath у меня содержит значение C:\Program Files\Microsoft\Exchange Server\V15

    Так а в чём проблема ? С вами никто и не спорит. Просто констатация факта, не более того :)

    =STAS=

    7 июня 2017 г. 23:10
  • Извините, просто ситуация была критической, никто не отвечал, вот и ... в общем, ситуация следующая:

    Есть DC на одном сервере и есть Exchange 2013 с прямым выходом в интернет - на другом.

    На этот, другой сервер была предпринята атака вируса WannaCry через SMB1, в результате чего был разрушен интерфейс внешнего входа через OWA (с чего всё, в принципе, и началось - позвонил юзер и сказал, что через браузер не зайти в почту) и ещё много чего было порушено на этом почтовом сервере.

    Интересно, что через Outlook 2016 почта работала. Также вирус удалил возможности восстановления посредством Windows Backup и теневые копии, поэтому восстановить систему из бэкапов не представилось возможным.

    Остался нетронутым DC и диск D, на котором находились сами базы с логами.

    Переустановив WinSrv2008R2, решил попробовать восстановить Exchange посредством "Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms", но CU7, который у меня стоял, я нигде не нашёл, а CU16 через команду "Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms" установился совсем криво так, что даже сразу после запуска не захотел запускаться.

    Теперь, опять переустановив WinSrv2008R2, попытаюсь сначала почистить AD от всех записей старого Exchange 2013 CU7, а потом, установив Exchange 2013 CU16, восстановить оставшиеся у меня базы данных EDB. Надеюсь, получится.


    =STAS=

    • Изменено -STAS- 7 июня 2017 г. 23:35
    7 июня 2017 г. 23:33
  • Что-то совсем плохая у вас идея. Сейчас так почистите AD, что вообще потом ничего не восстановите. 

    Вы .Net обновили до 4.6.2 перед установкой CU16? 

    Далее попробуйте на сервере, где установили CU16, прописать IP (127.0.0.1) для mail.regcon.local в файл hosts. Еще попробовать отключить IPv6. Имя сервера, надеюсь, оставили старое (mail.regcon.local)?

  • Уже почистил и установил новый Exchange 2013 CU16на новый WinSrv2008R2 с тем же именем. Учётку почтового сервера в AD переустановил. Установка прошла нормально, при первом же запуске не пускает ни в Shell? ни в админку.

    В Shell пишет:

    ПОДРОБНО: Подключение к mail.regcon.local.
    New-PSSession : [mail.regcon.local] Сбой подключения к удаленному серверу mail.regcon.local. Сообщение об ошибке: Клиен
    ту WinRM не удается обработать запрос. Невозможно определить тип содержимого ответа HTTP от компьютера назначения. Тип
    содержимого не является допустимым или отсутствует. Подробности см. в разделе справки "about_Remote_Troubleshooting".
    строка:1 знак:1
    + New-PSSession -ConnectionURI "$connectionUri" -ConfigurationName Microsoft.Excha ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
       gTransportException
        + FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed

    А при попытке входа в админку пишет:

    Поставщику топологии не удалось найти службу топологии Microsoft Exchange Active Directory на конечной точке "TopologyClientTcpEndpoint (localhost)".

    Только поставил, можно сказать, по-дефолту - уже не работает :(

    Да, Ipv6 отключён, mail.regcon.local так же и оставил название, не менял. .Net обновлял через Windows Update.


    =STAS=

    • Изменено -STAS- 8 июня 2017 г. 10:53
    8 июня 2017 г. 10:49
  • Мои рекомендации выполнили?
    8 июня 2017 г. 10:50
  • Да, всё выполнено. Запись 127.0.0.1 mail.regcon.local в hosts ничего не меняет.

    =STAS=

    • Изменено -STAS- 8 июня 2017 г. 10:56
    8 июня 2017 г. 10:54
  • Проверьте, запустились ли сервисы Exchange. Если нет, то попробуйте запустить и посмотрите, что пишется в EventLog. 
    8 июня 2017 г. 10:56
  • А какие именно сервисы ? Я так понимаю, в Службах надо смотреть ? Ещё читал, что WinRM нужно как-то включать.

    =STAS=

    8 июня 2017 г. 10:59
  • Начните с "Microsoft Exchange Active Directory". Да, в службах. 
    8 июня 2017 г. 11:01
  • Спасибо, что помогаете. Сейчас попробую.

    =STAS=

    8 июня 2017 г. 11:03
  • Службу Microsoft Exchange Active Directory включил (тип запуска стоял автоматически, но почему-то была отключена). Теперь в Shell пускает.

    В админке отображает окно входа, но при попытке входа пишет:

    https://localhost/owa/auth.owa

    Эта ошибка (HTTP 500 — внутренняя ошибка сервера) означает, что на веб-сайте произошел сбой сервера, который не позволяет отобразить веб-страницу.


    =STAS=

    8 июня 2017 г. 11:16
  • Ну вот, уже лучше. Теперь проверьте, чтобы все службы, у которых тип запуска "автоматически" были запущены. Далее можете выполнить iisreset (на всякий случай).
    8 июня 2017 г. 11:19
  • Еще можно сверить настройки IIS с таблицей:

    https://technet.microsoft.com/en-us/library/gg247612(v=exchg.150).aspx

    8 июня 2017 г. 11:20
  • Вы имеете ввиду только службы, относящиеся в Exchange ?

    =STAS=

    8 июня 2017 г. 11:20
  • Да все запускайте, не просто же так у них такой тип запуска. 
    8 июня 2017 г. 11:21
  • WOW !!! Запустилась админка !!! Наконец-то !!! 2 ночи не спал уже !!! Спасибо большое вам !!!

    Запустил следующие службы:

    Microsoft Exchange EdgeSync
    Microsoft Exchange Service Host
    Банк данных Microsoft Exchange
    Диспетчер работоспособности Microsoft Exchange
    Единая система обмена сообщениями Microsoft Exchange
    Интерфейсный транспорт Microsoft Exchange
    Клиентский доступ к Microsoft Exchange RPC
    Маршрутизатор вызовов единой системы обмена сообщениями Microsoft Exchange
    Обновление средства защиты от нежелательной почты Microsoft Exchange
    Помощники по обслуживанию почтовых ящиков Microsoft Exchange
    Регулирование Microsoft Exchange
    Репликация Microsoft Exchange
    Репликация почтовых ящиков Microsoft Exchange
    Служба поиска Microsoft Exchange
    Транспорт Microsoft Exchange
    Транспортная доставка почтовых ящиков Microsoft Exchange
    Транспортная отправка почтовых ящиков Microsoft Exchange
    Управление Microsoft Exchange DAG

    В админке даже пользователей нашёл, правда, при выборе пользователя пишет:

    Предупреждение:
    Объект regcon.local/Users/User A.A. поврежден и находится в несогласованном состоянии. При проверке выявлены следующие ошибки:

    Параметр Database является обязательным на UserMailbox.


    =STAS=

    • Изменено -STAS- 14 июня 2017 г. 12:29
    8 июня 2017 г. 11:36
  • Ну с базами данных оно понятно - они забэкаплены в другом месте и теперь из них как-то надо достать данные пользователей и вставить в новую базу. Кстати, хотелось бы создать новую базу на другом, большом диске, и уже туда залить данные из старых бекапленных баз. Там их всего 2 - основная и архивная, стандартно. Есть какие-нибудь идеи по этому поводу ?

    =STAS=

    8 июня 2017 г. 11:45
  • Да, проблема известная. Начните с Arbitration Mailbox:

    Set-Mailbox “SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}” -Arbitration -Database “YourDatabaseNameHere”

    Пруфлинк:

    https://social.technet.microsoft.com/wiki/contents/articles/25342.exchange-2013-setup-error-database-is-mandatory-on-usermailbox.aspx

    Базы данных поднялись корректно? Статус "Mounted"?

    Так же можно удалить все Health mailbox (учетные записи в AD) и перезапустить "Exchange Health Manager service".

    8 июня 2017 г. 11:46
  • А зачем бэкапы баз? Они же не были зашифрованы? Вы их удалили при пересоздании сервера?

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

    8 июня 2017 г. 11:48
  • Да, еще можете сразу большому диску задать букву, которая была у старого маленького диска :) И уже на него восстановить базу из бэкапа. Возможно надо будет поправить права на папки.
    8 июня 2017 г. 11:50
  • Базы восстановил из бэкапов, но в другое место, на том же диске, но в папку _Old. Только дело в том, что в старой установке я Exchange устанавливал на диск D, а здесь решил поставить на C, а базы скинуть на D:

    Базы не шифровал. И логи должны быть целы в принципе.


    =STAS=

    8 июня 2017 г. 11:59
  • Важен только путь к базам данных. Поэтому разместите базы на диске D, как на старом сервере. А потом перезапустите службу Store (как в локализованной версии она называется не знаю). Или сразу "Microsoft Exchange Active Directory" (она потянет за собой остальные службы Exchange). 
    8 июня 2017 г. 12:12
  • Интересно: после вставки файлов Exchange на своё прежнее место на D: (сам Exchange теперь на C:) и перезагрузки опять те же проблемы со входом. Эти службы надо постоянно вручную включать что ли ?

    =STAS=

    8 июня 2017 г. 12:15
  • Все файлы поставил обратно туда, где они были, но всё равно у пользователей в графе "База данных" пусто. Возможно, из-за того, что AD почистил от старого Exchange. И всё же, почему-то опять службы Exchange не запустились автоматом после перезагрузки ...

    =STAS=


    • Изменено -STAS- 8 июня 2017 г. 12:24
    8 июня 2017 г. 12:22
  • В общем, старые базы и логи положил туда, где они и были - на диск D, но Exchange их не подцепляет. Видимо, из-за того, что почистил AD ... Чистил AD по этому гайду:

    http://smtp25.ru/archives/1054 - по сценарию 3

    Есть ещё какие-то варианты ? Например, создать новую базу данных на большом диске D и как-то залить туда данные со старых баз ?

    И интересно всё же, почему после перезагрузки сервера службы не запускаются автоматически, хотя в типе запуска стоит автоматом ...


    =STAS=

    • Изменено -STAS- 8 июня 2017 г. 12:54
    8 июня 2017 г. 12:54
  • 1. как подключить базы описано тут: https://technet.microsoft.com/en-us/library/dd876926%28v=exchg.160%29.aspx?f=255&MSPPError=-2147217396

    2. >>http://smtp25.ru/archives/1054 - по сценарию 3

    "Сценарий 3. Удаление Exchange организации в целом"

    вы это зачем, я не очень понял? или вы новую организацию создавали при повторной установке?

    3. >>И интересно всё же, почему после перезагрузки сервера службы не запускаются автоматически, хотя в типе запуска стоит автоматом

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


    MCSAnykey


    8 июня 2017 г. 13:08
  • Ну, хотел всё по-новой, с чистого листа, так сказать, чтоб без старых глюков. А базы думал потом просто импортировать и всё.

    =STAS=

    8 июня 2017 г. 13:14
  • Ну вы и нагородили... Реально было работы на час. Теперь задача творческая. В крайнем случае можно пересоздать ящики и восстановить их каждый отдельно из бэкапа:

    https://technet.microsoft.com/ru-ru/library/ee332351(v=exchg.160).aspx

    Но я бы попробовал все же примонтировать базы. Например, создать новую и подменить файлы, потом поменять значение параметра "Database" для пользователей (если не получится через PowerShell, можно через ADSI). Но реально - кейс резко стал нестандартным :)

    8 июня 2017 г. 13:19
  • Ну, хотел всё по-новой, с чистого листа, так сказать, чтоб без старых глюков. А базы думал потом просто импортировать и всё.

    =STAS=

    Пока вы там совсем в дебри не зашли: имя ексчендж организации вы поменяли при новой установке? Или все-таки старое оставили может?:)

    MCSAnykey

    8 июня 2017 г. 13:25
  • Вопрос по ссылке - в пункте 4:

    "Переместите файлы базы данных (EDB-файл, файлы журналов и каталог поиска Exchange ) в папку базы данных, указанную при создании новой базы данных."

    Я не совсем понял - то есть в общем предлагается создать новую DB и в эту же директорию положить старую DB  и логи и примонтировать их, так ?


    =STAS=

    8 июня 2017 г. 13:34
  • Дело в том, что ещё не было уверенности, что всё пройдёт нормально, т.к. старый Exch - CU7, а новый - CU16. А старого CU7 я нигде не нашёл, даже в английской версии технета задавал вопрос - сказали, что надо делать тикет и спрашивать у MS.

    =STAS=

    8 июня 2017 г. 13:37
  • Вы в данном случае ничем не рискуете (если не удалили бэкапы). Поэтому делайте все по мануалу. 
    8 июня 2017 г. 13:38
  • Всё оставил по-старому, только учётку mail.regcon.local переуcтановил в AD.

    =STAS=

    • Изменено -STAS- 8 июня 2017 г. 13:54
    8 июня 2017 г. 13:47
  • Скажу больше, есть даже бэкапы DC до "чистки" AD от старого Exchange CU7, так что могу DС восстановить в режиме "Восстановления службы каталогов", а потом поставить заново Exchange 2013 CU16 в режиме REPAIR ... Возможно, так будет проще, раз с простой установкой заново такие сложности.

    =STAS=

    • Изменено -STAS- 8 июня 2017 г. 13:51
    8 июня 2017 г. 13:49
  • Ну вы уже попробуйте подключить базы данных. Если не получится, то правильнее будет выполнить откат контроллеров домена и переустановку Exchange в режиме восстановления. 
    8 июня 2017 г. 13:55
  • Кстати, смена типа запуска на "Автоматически - отложенный" всех служб Exchange, у которых стоял тип запуска "Автоматический", которые не запустились - помогла, спасибо.

    =STAS=

    8 июня 2017 г. 13:59
  • Одно "но" - если есть такая проблема с запуском служб, это свидетельствует о каких-то проблемах. Вероятнее всего, это низкая производительность сервера (медленная СХД, мало CPU/RAM). Поэтому к данному вопросу все же вернитесь, когда будет восстановлена работа почты.
    8 июня 2017 г. 14:04
  • Пробую ...

    =STAS=

    8 июня 2017 г. 14:18
  • Да не, с производительностью всё норм - серверная мать Intel начального уровня правда, система на SSD в RAID, памяти 32ГБ. Юзеров чуть больше 50. Не должно быть - скорее, мне кажется, что-то с настройками. Либо осталось что-то в AD от старой Exchange и новая пытается там что-то найти, чего уже нет ... Вот и задержка возникает.

    =STAS=


    • Изменено -STAS- 8 июня 2017 г. 14:23
    8 июня 2017 г. 14:21
  • "Вы игнорировали мой вопрос относительно магнитофона" (С):

    Вопрос по ссылке - в пункте 4:

    "Переместите файлы базы данных (EDB-файл, файлы журналов и каталог поиска Exchange ) в папку базы данных, указанную при создании новой базы данных."

    Я не совсем понял - то есть в общем предлагается создать новую DB и в эту же директорию положить старую DB  и логи и примонтировать их, так ?


    =STAS=

    8 июня 2017 г. 14:23
  • Да, я бы попробовал так. После этого указать параметр Database для почтовых ящиков. Я об этом выше писал :)
    8 июня 2017 г. 14:25
  • Я не совсем понял - то есть в общем предлагается создать новую DB и в эту же директорию положить старую DB  и логи и примонтировать их, так ?


    =STAS=

    Так. Только прежде чем положить туда старую базу, нужно убедиться, что она в состоянии clean shutdown - вы это не проигнорировали?

    MCSAnykey

    8 июня 2017 г. 14:31
  • Нет, не проигнорировал.

    В общем, создал через админку новую базу d:\testdb\test.edb с логами в d:\testlogs, скопировал в d:\testdb одну из двух баз, при попытке Mount-Database пишет:

    [PS] C:\Users\Administrator\Desktop>Mount-Database Archive
    Не удалось выполнить операцию, поскольку объект "Archive" не найден в "DC.regcon.local".
        + CategoryInfo          : NotSpecified: (:) [Mount-Database], ManagementObjectNotFoundException
        + FullyQualifiedErrorId : [Server=MAIL,RequestId=63d0a129-3adc-434e-872b-a77193368919,TimeStamp=08.06.2017 14:41:1
       4] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] FC89E88,Microsoft.Exchange.Management.SystemConfigur
      ationTasks.MountDatabase
        + PSComputerName        : mail.regcon.local


    =STAS=


    • Изменено -STAS- 8 июня 2017 г. 14:51
    8 июня 2017 г. 14:47
  • у вас контроллеров домена сколько? может быть, репликация не прошла после того, как вы создали базу.

    запустите репликацию\подождите и попробуйте смонтировать заново.


    MCSAnykey

    8 июня 2017 г. 14:51
  • Одно "но" - если есть такая проблема с запуском служб, это свидетельствует о каких-то проблемах. Вероятнее всего, это низкая производительность сервера (медленная СХД, мало CPU/RAM).

    ... или включенный STP на порту коммутатора, к которому подключен сервер: для Exchange вполне может хватить тех 50 секунд, которое, согласно протоколу, проходят между стартом драйвера (драйвер часто заново производит согласование скорости/дуплекса) и началом прохождения трафика, чтобы словить таймаут обращения к контроллеру домена.

    Слава России!

    8 июня 2017 г. 15:17
  • Журналы транзакций должны быть в той же директории, что и база данных ?

    =STAS=

    8 июня 2017 г. 15:28
  • Журналы транзакций должны быть там, где вы сами им сказали быть, создавая базу.

    MCSAnykey

    8 июня 2017 г. 16:27
  • один КД

    =STAS=

    8 июня 2017 г. 16:45
  • Я имею ввиду тот случай, когда мы создаём новую базу и в это же место кидаем старую базу в состоянии Clean Shutdown... Логи туда же кидать, чтобы примонтировать эту старую базу?

    =STAS=

    8 июня 2017 г. 16:47
  • >>В общем, создал через админку новую базу d:\testdb\test.edb с логами в d:\testlogs, скопировал в d:\testdb одну из двух баз, при попытке Mount-Database пишет: [PS] C:\Users\Administrator\Desktop>Mount-Database Archive
    Поясните, вы базу через эту самую админку создали с каким именем? Archive или какой-нибудь Test? А еще лучше покажите вывод get-mailboxdatabase.
    Давайте лучше по порядку, а то понять, что и как вы создали, и что и чем заменяете потом, почти нереально.

    MCSAnykey

    8 июня 2017 г. 17:34
  • В общем, при попытке восстановления единственный наш КД накрылся медным тазом. Создал отдельную тему для этого в WinSrv2008R2 форуме. Так что пока тема по Эксчу приостановлена. Честно говоря, полный ....

    =STAS=

  • В итоге восстановил Exchange, но базы ... Состояние: Активна, Отключена, Состояние индекса содержимого: Ошибка ... Слышал что-то о базах данных восстановления ... может, через них надо действовать ?

    =STAS=

    12 июня 2017 г. 18:08
  • КД еле-еле удалось восстановить в состояние на ноябрь 2015 года ... Установил новый WinSrv2008R2 для Exchange, поставил Exchange с ключиком Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms, перезапустил сервер, опять службы не запускаются, хотя стоит автоматический запуск, поставил отложенный запуск - завелась Exchange. Даже пользователей нашла, правда некоторый новых не нашла (всё-таки КД на состояние 2015г восстановлен), зато нашлись старые, которых уже нет :)

    Но базы данных в состоянии "Активна, Отключена, Состояние индекса содержимого: Ошибка"

    Да, попробовал esetutil - пишет, базы в состояниие Dirty


    =STAS=

    • Изменено -STAS- 13 июня 2017 г. 18:06
    12 июня 2017 г. 18:20
  • В любом случае надо перевести базу в Clean Shutdown. Выше Егор давал ссылку, где описана работа с eseutil:

    https://practical365.com/exchange-server/restore-exchange-server-2013-database-recovery-database/

    Попробуйте, может она примонтируется.

    12 июня 2017 г. 20:13
  • Спасибо, Артём, за помощь.

    Просто дело в том, что на ноябрь 2015 года каких-то пользователей не было ещё в домене, а в базе они должны быть. Боюсь, удалятся из базы. Можно как-нибудь восстановить базу и посмотреть, кто в ней есть, а кого нет, чтобы не потерять почту пользователей ?


    =STAS=

    13 июня 2017 г. 8:42
  • Да, конечно можно. Для этого подключите базу как Recovery. Как вариант, примерно так:

    1. Убедитесь, что бэкап базы данных есть и его можно восстановить.

    2. С помощью eseutil переведите базу в Clean Shutdown

    3. Скопируйте базу в новое расположение (потом подключим ее как Recovery)

    4. Попробуйте выполнить Mount-Database для восстановленной базы данных. Возможно, часть ящиков заработает. Если так, то потом создайте новую базу данных и мигрируйте в нее ящики. 

    5. Вторую копию базы (из п.3) подключите как Recovery (есть в статье выше). Вы можете посмотреть и восстановить ящики.

    13 июня 2017 г. 8:51
  • А чего вы боитесь? У вас ведь должна быть копия базы. Если что-то похерите, то заново подключите старую БД в базу восстановления и вытащите данные.

    Также совершенно непонятно почему вы восстановили кд на состояние двухлетней давности. Почему не подняли последнюю копию?

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

    13 июня 2017 г. 8:59
  • По поводу восстановления отдельных почтовых ящиков, вот вам гайд: http://blog.bissquit.com/mail-servers/exchange-server/exchange2013-mailbox-restore/

    Собственно последовательность в точности как расписал Артем чуть выше.

    Список ящиков внутри базы восстановления сможете вытащить командой: 

    Get-MailboxStatistics -Database recovery | ft DisplayName,MailboxGUID,ItemCount -AutoSize

      
    13 июня 2017 г. 9:08
  • Пока что не получилось использовать софт рекавери.

    Действия:

    1. Попробовал eseutil /mh в директории с живой базой - пишет ошибка доступа.

    2. Скопировал базу с логами (у меня всё в одной директории почему-то по-умолчанию) на другой диск.

    3. Проверяю базу:

    eseutil /mh "E:\RecoveryDB\Mailbox Database 0305871278.edb"

    Dirty Shutdown

    4. Пробую софт рекавери:

    eseutil /r E00 /l E:\RecoveryDB /d E:\RecoveryDB

    Пишет, операция завершена.

    5. Опять проверяю базу:

    eseutil /mh "E:\RecoveryDB\Mailbox Database 0305871278.edb"

    Опять Dirty Shutdown ...

    6. Теперь пробую хард рекавери - что-то вроде пошло ...

    eseutil /p "Mailbox Database 0305871278.edb"

    7. Вроде восстановилась основная база, долго месил, теперь вместо 114ГБ получилось 116ГБ. Делаю копию. Теперь ещё надо архивную базу рекаверить.


    =STAS=


    • Изменено -STAS- 13 июня 2017 г. 16:03
    13 июня 2017 г. 15:25
  • После eseutil /p базу удалось подмонтировать?
    13 июня 2017 г. 16:33
  • Пока ещё не монтировал - читаю, как это делается. Честно говоря, не совсем понимаю, какой командой монтировать и зачем подключать recovery database, если эта заработает ... Вообще система не понятна, в ссылках много детальной информации, но общую простую картину не могу у себя в голове сложить. Для чего нужны Recovery databases, как надо делать - создавать эту рекавери, потом подключать восстановленную базу и из неё в рекавери сливать ? Или . в общем, запутался что-то к вечеру ...

    =STAS=


    • Изменено -STAS- 13 июня 2017 г. 16:45
    13 июня 2017 г. 16:42

  • Можно как-нибудь восстановить базу и посмотреть, кто в ней есть, а кого нет, чтобы не потерять почту пользователей ?


    =STAS=

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


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

    in other recovery scenarios you may only want to recover one or several mailboxes, or even specific mailbox items

    То есть, если вы хотите восстановить отдельные ящики, а не базу целиком, то делайте как написано в статье.

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

    13 июня 2017 г. 16:56
  • Не хочет монтироваться. Хотя состояние Clean Shutdown уже. Пишет:

    [PS] E:\recoverydb>Mount-Database "Mailbox Database 0305871278.edb"

    Не удалось выполнить операцию, поскольку объект "Mailbox Database 0305871278.edb" не найден в "SERVER-ZAO.regcon.local"
    .
        + CategoryInfo          : NotSpecified: (:) [Mount-Database], ManagementObjectNotFoundException
        + FullyQualifiedErrorId : [Server=MAIL,RequestId=89acc587-8cb7-461a-9ef3-fc827fd65ade,TimeStamp=13.06.2017 17:13:5
       6] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 16E2CAC4,Microsoft.Exchange.Management.SystemConfigu
      rationTasks.MountDatabase
        + PSComputerName        : mail.regcon.local


    =STAS=

    13 июня 2017 г. 17:18
  • Не пойму, вы базу восстановления создали? Или вы просто скопировали .edb вместе со всеми файлами и пытаетесь его сейчас смонтировать?
    13 июня 2017 г. 18:11
  • Очень похоже на то. Ровно как и предыдущий раз, когда я об этом же спросил и попросил показать вывод get-mailboxdatabase.
    А ТС вместо этого, весело махнув шашкой, побежал уничтожать лес AD:)

    MCSAnykey

    13 июня 2017 г. 18:31
  • Просто скопировал ... Ребят, ну в первый раз восстанавливаю, еле КД восстановил, поседел за эти выходные, а директора денег жмут, а сроки требуют побыстрее ... поймите меня правильно, я без плохого умысла ...

    =STAS=

    • Изменено -STAS- 13 июня 2017 г. 19:04
    13 июня 2017 г. 18:58
  • Спасибо, посмеялся от души за ваш пост "махнув шашкой" :):):)

    Насчёт get-mailboxdatabase:

    [PS] E:\temp>get-mailboxdatabase
    Name                           Server          Recovery        ReplicationType
    ----                           ------          --------        ---------------
    Mailbox Database 0305871278    MAIL            False           None
    Archive                        MAIL            False           None


    =STAS=

    13 июня 2017 г. 19:00
  • Mount-Database "Mailbox Database 0305871278"

    или 

    get-mailboxdatabase | Mount-Database

    Ошибка в том, что вы добавили .edb в команду. Попробуйте смонтировать базу пока так, без рекавери. Мне самому интересно, что получится :) Хуже уже не будет, не бойтесь :)

    13 июня 2017 г. 19:13
  • Только директория переименовал из RecoveryDB  в CleanDB, думаю, это ничего, ведь эта директория не прописана нигде ?

    [PS] E:\>cd cleandb
    [PS] E:\cleandb>Mount-Database "Mailbox Database 0305871278"
    Не удалось подключить базу данных Mailbox Database 0305871278. Ошибка: Сбой операции Active Manager. Ошибка: Сбой дейст
    вия базы данных. Ошибка: Сбой операции с сообщением: MapiExceptionDatabaseError: Unable to mount database. (hr=0x800040
    05, ec=1108)
    Diagnostic context:
        Lid: 65256
        Lid: 10722   StoreEc: 0x454
        Lid: 1494    ---- Remote Context Beg ----
        Lid: 45120   dwParam: 0x5A5CC1
        Lid: 57728   dwParam: 0x5A5CEF
        Lid: 46144   dwParam: 0x5A5D7C
        Lid: 34880   dwParam: 0x5A5D7C
        Lid: 34760   StoreEc: 0xFFFFFB40
        Lid: 41344   Guid: 5a32932c-a72f-4c28-aa75-effeaedc56d0
        Lid: 35200   dwParam: 0x1F9C
        Lid: 46144   dwParam: 0x5A628B
        Lid: 34880   dwParam: 0x5A628B
        Lid: 54472   StoreEc: 0x1388
        Lid: 42184   StoreEc: 0x454
        Lid: 1750    ---- Remote Context End ----
        Lid: 1047    StoreEc: 0x454      [База данных: Mailbox Database 0305871278, Сервер: MAIL.regcon.local].
        + CategoryInfo          : InvalidOperation: (Mailbox Database 0305871278:ADObjectId) [Mount-Database], InvalidOper
       ationException
        + FullyQualifiedErrorId : [Server=MAIL,RequestId=d9a510a3-1d68-4f32-af22-d0a2debd2506,TimeStamp=13.06.2017 19:23:3
       1] [FailureCategory=Cmdlet-InvalidOperationException] AFA7D5B6,Microsoft.Exchange.Management.SystemConfigurationTa
      sks.MountDatabase
        + PSComputerName        : mail.regcon.local

    В общем, не монтируется, хотя и чистая. Может, надо создать RecoveryDatabase и туда кинуть содержимое e:\CleanDB ?


    =STAS=

    13 июня 2017 г. 19:27
  • Не понял про "директория не прописана нигде". Вы должны были 'починить' старый edb, и заменить этим починенным edb тот, что лежит в вашей базе, которая не монтируется.
    Покажите вывод Get-MailboxDatabase | fl Name,EdbFilePath,LogFolderPath и сравните с тем путем, где у вас файлы лежат.

    MCSAnykey



    13 июня 2017 г. 19:41
  • [PS] E:\cleandb>Get-MailboxDatabase | fl Name,EdbFilePath,LogFolderPath

    Name          : Mailbox Database 0305871278
    EdbFilePath   : D:\Exchange\V15\Mailbox\Mailbox Database 0305871278\Mailbox Database 0305871278.edb
    LogFolderPath : D:\Exchange\V15\Mailbox\Mailbox Database 0305871278
    Name          : Archive
    EdbFilePath   : D:\Exchange\V15\Mailbox\Archive\Archive.edb
    LogFolderPath : D:\Exchange\V15\Mailbox\Archive

    Т.е. надо было создать RecoveryDB и потом туда же положить починенный DB ? Я правильно понял ?

    Или если как вы говорите "заменить", то как ? Что, прямо с перезаписью на живую базу (хотя она уже и не живая ...). Что-то страшновато  ... Итак наломал дров уже ...


    =STAS=

    • Изменено -STAS- 13 июня 2017 г. 20:06
    13 июня 2017 г. 19:58
  • Только директория переименовал из RecoveryDB  в CleanDB, думаю, это ничего, ведь эта директория не прописана нигде ?



    =STAS=

    Посмотрите на команду, которую вы сами и выполняли:

    eseutil /r E00 /l E:\RecoveryDB /d E:\RecoveryDB

    Как думаете, зачем тут параметры /l и /d и что они означают?

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

    13 июня 2017 г. 20:05
  • Ключ /l - где находятся логи для восстановления, ключ /d - где находится база для восстановления. Ну, посмотрел eseutil в эти места, нашёл там и базу и логи, восстановил.  Вы хотите сказать, что он теперь эти пути куда-то в AD или в Exchange прописал попутно ?

    =STAS=

    13 июня 2017 г. 20:10
  • В случае с recovery database вы сначала чините едб-шник eseutil'ом, а затем на основе его местоположения и логов создаете базу:
    https://technet.microsoft.com/en-us/library/ee332351(v=exchg.160).aspx
    То что писал я - это если вы просто файл базы пытаетесь подменить:
    https://technet.microsoft.com/en-us/library/dd876926(v=exchg.150).aspx

    MCSAnykey

    13 июня 2017 г. 20:13
  • Окей, так какой вариант мне использовать лучше ? Что делать конкретно ? Вот я сейчас имею базу в состоянии Clean Shutdown. А кривая (Dirty) - находится на сервере.

    P.S.: На всякий случай переименовал директорию CleanDB обратно в RecoveryDB.

    =STAS=

    • Изменено -STAS- 13 июня 2017 г. 20:52
    13 июня 2017 г. 20:20
  • >>Вот я сейчас имею базу в состоянии Clean Shutdown. А кривая (Dirty) - находится на сервере.

    Что это означает, я не понял.

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

    Я бы для начала попробовал подменить файл edb вашей погибшей базы (Archive или как она там называется) на тот, починенный eseutil'ом. В случае успешности этой операции (полный список шагов по ссылке описан) клиенты, которым эта база назначена, должны увидеть свои ящики сразу, без дополнительных телодвижений.

     

    MCSAnykey

    14 июня 2017 г. 6:21
  • В общем сначала я пошёл первым путём, через базу восстановления:

    https://practical365.com/exchange-server/restore-exchange-server-2013-database-recovery-database

    Имеем:

    1. Исходную базу скопировал и почистил

    2. Создал RecoveryDB на её основе

    3. Подключил эту RecoveryDB

    4. НО: При попытке восстановления ящика полностью:

    New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox "Administrator" -TargetMailbox Administrator -AllowLegacyDNMismatch

    выдаёт вот такую ошибку:

    Не удалось подключиться к базе данных почтовых ящиков.
        + CategoryInfo          : ResourceUnavailable: (:) [New-MailboxRestoreRequest], MailboxOfflineException
        + FullyQualifiedErrorId : [Server=MAIL,RequestId=320ef5c8-cb3e-4ec1-a780-c8bd2e100d7b,TimeStamp=14.06.2017 10:04:5
       7] [FailureCategory=Cmdlet-MailboxOfflineException] 2BF81567,Microsoft.Exchange.Management.RecipientTasks.NewMailb
      oxRestoreRequest
        + PSComputerName        : mail.regcon.local

    ЛАДНО, думаю, пойдём другим путём, через переносимость баз данных:

    https://technet.microsoft.com/ru-ru/library/dd876926(v=exchg.150).aspx

    Создаём новую базу данных:

    New-MailboxDatabase -Name DB1 -Server MAIL -EdbFilePath D:\Exchange\V15\Mailbox\DB1\DB1.edb -LogFolderPath D:\Exchange\V15\Mailbox\DB1

    Перезапускаем службу Банк данных MS Exchange

    Устанавливаем атрибут "This database can be over written by restore":

    Set-MailboxDatabase DB1 -AllowFileRestore $true

    Перемещаем базу данных с уже достигнутым состоянием CleanShutdown в эту новую папку с новой базой данных

    Подключаем её:

    Mount-Database DB1

    Переносим пользователей из старой базы данных в новую:

    Get-Mailbox -Database "Mailbox Database 0305871278" |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Set-Mailbox -Database DB1

    ... слава богу, хватило ума после переноса меня (Administrator), стопануть остальной процесс (он после каждого пользователя спрашивает) и посмотреть, что получилось.

    А получилось вот что: вхожу через OWA  в свою почту и там - ПУСТО ! Смотрю через админку - я уже в новой базе данных DB1, но в почте пусто ! Вот так перенос !

    Уж и не знаю, что делать ... Вроде бы и база данных есть, и в нормальном состоянии, а данные оттуда не достать никак ! Всего 50 пользователей - может, хоть как-то из этой базы в PST-файлы слить, я бы потом сам залил обратно. Какой-то бред ! Ну не выходит каменный цветок никак !


    =STAS=

    • Изменено -STAS- 14 июня 2017 г. 12:50
    14 июня 2017 г. 9:19
  • В общем, почему-то не работает ни первый вариант, ни второй ...

    =STAS=

    14 июня 2017 г. 12:44
  • >>New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox "Administrator" -TargetMailbox Administrator -AllowLegacyDNMismatch

    В у вас этот самый TargetMailbox Administrator имеется, и так, чтоб живой, куда вы собрались восстанавливать ящик-то? Для этого нужно иметь живую обычную базу (создать, если нет), и сделать то, что вы там ниже делаете: Set-Mailbox administrator -Database какая-то-база. И после этого уже ресторить элементы из реквавери базы в живую.

    Что вы стали делать с подменой едб для меня чёт вообще загадка.

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

    >>Get-Mailbox -Database "Mailbox Database 0305871278" |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Set-Mailbox -Database DB1

    Этой командой вы ничего никуда не переместили, а сказали пользователям, которые в той базе жили, что они теперь живут в базе DB1. И они с радостью себе там сделали новый ящик. А старый (восстановленный ящик) я так подозреваю в статусе disconnected там болтается, проверьте:

    Get-MailboxStatistics -database DB


    MCSAnykey

    14 июня 2017 г. 13:29
  • ДААА !!! Наконец-то !!! Я всё понял теперь и ОГРОМНОЕ СПАСИБО ВСЕМ, кто помог мне в этом разобраться, тест восстановления на моём личном ящике прошёл успешно !!!

    Короче, общая схема успешного восстановления базы данных Exchange 2013 у меня получилась такая:

    1. Восстанавливаем грохнутую базу данных

    2. Делаем RecoveryDB на основе грохнутой
    3. Создаём новую базу данных
    4. Переносим данные из RecoveryDB в новую базу данных


    Итак, грохнулась база "Mailbox Database 0305871278.edb"
    ///Копируем папку с базой в другое место
    ///Проверяем базу данных:
    eseutil /mh "E:\RecoveryDB\Mailbox Database 0305871278.edb"
    ///Пытаемся восстановить мягко:
    eseutil /r E00 /l E:\RecoveryDB /d E:\RecoveryDB
    ///Ещё раз проверяем:
    eseutil /mh "E:\RecoveryDB\Mailbox Database 0305871278.edb"
    (по-хорошему не хочет :)
    ///Восстанавливаем жёстко:
    eseutil /p "Mailbox Database 0305871278.edb"
    ///Создаём на основе восстановленой базы данных Recovery DB:
    New-MailboxDatabase -Server MAIL -Name RecoveryDB -Recovery -EdbFilePath "E:\RecoveryDB\Mailbox Database 0305871278.edb"
    ///Перезапускаем службу Банк данных MS Exchange
    ///Монтируем базу восстановления:
    Mount-Database RecoveryDB
    ///Проверяем, что внутри базы (есть ли там вообще что-либо):
    Get-MailboxStatistics -Database RecoveryDB | ft -auto
    ///Делаем новую базу Данных в желаемом месте:
    New-MailboxDatabase -Name DB1 -Server MAIL -EdbFilePath D:\Exchange\V15\Mailbox\DB1\DB1.edb -LogFolderPath D:\Exchange\V15\Mailbox\DB1
    ///Устанавливаем атрибут This database can be over written by restore:
    Set-MailboxDatabase DB1 -AllowFileRestore $true
    ///Перезапускаем службу Банк данных MS Exchange
    ///Монтируем новую базу DB1:
    Mount-Database DB1
    ///Перезапускаем службу Банк данных MS Exchange
    ///Переносим записи AD всех пользователей из старой базы с длинным названием в новую базу DB1 (переносятся только записи в AD, не сами данные):
    Get-Mailbox -Database "Mailbox Database 0305871278" |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Set-Mailbox -Database DB1

    ///Восстанавливаем почтовые ящики по одному из RecoveryDB в новую базу данных DB1:
    New-MailboxRestoreRequest -SourceDatabase RecoveryDB -SourceStoreMailbox UserName -TargetMailbox UserName -AllowLegacyDNMismatch

    Всё верно сделал ?


    =STAS=

    • Изменено -STAS- 14 июня 2017 г. 15:34
    14 июня 2017 г. 15:27
  • https://blogs.technet.microsoft.com/fun_with_powershell/2013/04/26/new-mailboxrestorerequest-bulk-mailbox-merge-how-to-do-that/ чтоб по одному ящики не восстанавливатьну

    и под конец вы что-то зачастили с этим через каждый шаг: "Перезапускаем службу Банк данных MS Exchange"

    Set-MailboxDatabase DB1 -AllowFileRestore $true - не нужно там AllowFileRestore, вы ж файлы не меняете.

    ну и вообще, самый первый шаг должен быть оценкой времени восстановления, и если времени потребуется много, то вот это

    Get-Mailbox -Database "Mailbox Database 0305871278" |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'}| Set-Mailbox -Database DB1

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

    жаль, за 100 сообщений не перевалили:)


    MCSAnykey

    14 июня 2017 г. 15:47
  • Насчёт по одному ящику не восстанавливать - мне так спокойнее - пользователей не так много, а воды утекло много - кто приходил, кто уходил, лучше вручную, но на будущее - спасибо.

    Насчёт зачастили ... точно был не уверен, но лишний раз не помешает

    С filerestore теперь ясно, спасибо


    =STAS=

    14 июня 2017 г. 17:16
  • Да, за 100 не перевалило ... пока ... но тут ещё одна ошибка вывалилась, даже две:

    1. В Центре администрирования Exchange при попытке входа на вкладку "Миграция" пишет:

    Не удается открыть почтовый ящик /o=REGCON/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=MAIL/cn=Microsoft System Attendant.

    Нажмите здесь для получения справки

    2. Не открывается Exchange Toolbox - MMC ругается, что оснастка может быть установлена неправильно ...

    3. И если вы ещё не устали от моих вопросов, то интересно ещё, там есть N-ное количество почтовых ящиков Exchange? всякие HealthMailbox, какой-то помощник по самоутверждению, SystemMailbox и прочие - с ними что делать ?

    4. Да, ещё странно, при проверке одного из переносимых ящиков

    Get-MailboxRestoreRequest -RequestQueue DB1

    выдал мне статус Failed ... хотя захожу в этот ящик через OWA - вроде всё нормально. Это бывает ?


    =STAS=

    • Изменено -STAS- 14 июня 2017 г. 17:42
    14 июня 2017 г. 17:18
  • По пункту 1 смотрите сюда: https://blogs.msdn.microsoft.com/ashour/2014/07/04/tip-of-the-day-system-attendant-mailbox-and-exchange-2013/

    По пункту 3 то же самое, тут в картинках нарисовано: https://jaapwesselius.com/2015/10/14/exchange-2013-recreate-arbitration-mailboxes/ (только не удаляйте Migration, который в пункте 1 создается и включается).

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

    4. Смотрите, почему реквест зафейлился:

    Get-MailboxRestoreRequest -Status failed | Get-MailboxRestoreRequestStatistics

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


    MCSAnykey

    15 июня 2017 г. 9:05
  • Пункт 1 - Действительно, помогло, спасибо большое !

    Остальные пункты ещё делаю

    Ещё вопрос нарисовался:

    Обнаружил, что кое-каеи-системные или как их там ящики ещё привязаны к старой нерабочей базе. Что с этим делать ? Просто удалить и Exchange сам их восстановит ?


    =STAS=

    15 июня 2017 г. 10:35
  • ну вообще можно наверное их восстановить попробовать, но я б на это забил и удалил бы.

    по второй ссылке написано, как с ними быть: они создаются заново при setup /preparead, а затем надо их заенаблить (в общем-то это есть именно то, что вы в пункте 3 спрашивали сначала)


    MCSAnykey

    15 июня 2017 г. 11:31
  • Окей, спасибо. По пункту 3 - всё сделал, как там написано (там ещё ошибочка была - исправил), ящики заэнаблил , квоту дал 1 МБ, имя поменял на Exchange ... и т.д. Команду вашу выполнил по поводу почему ящики перенеслись с ошибкой - пишет слишком много слишком больших файлов (что бы это значило) ...

    Да, ещё удалил ящики HealthMailbox - думал, пересоздадутся после /PrepareAD - что-то нет их до сих пор ...


    =STAS=

    15 июня 2017 г. 12:20
  • >>Да, ещё удалил ящики HealthMailbox - думал, пересоздадутся после /PrepareAD - что-то нет их до сих пор ...

    перезапустите службу Exchange Health Manager или сервер:)

    >>Команду вашу выполнил по поводу почему ящики перенеслись с ошибкой - пишет слишком много слишком больших файлов (что бы это значило)

    оригинал ошибки покажите


    MCSAnykey

    15 июня 2017 г. 12:25
  • Много больших файлов - то и значит. Правьте MaxReceiveSize (можно сразу для всех через Get-Mailbox | Set-Mailbox -Maxreceivesize 35MB)

    HealthMailbox восстановятся после рестарта сервиса MSExchangeHM (Health Manager). 

    15 июня 2017 г. 12:28
  • Ящики Health не пересоздаются ни после рестерта службы, ни после рестарта сервера :(

    оригинал ошибки по переносу ящиков (один из...):

    RunspaceId                             : d05b1fc5-acaf-4c72-928b-1d158c44366e
    Name                                   : MailboxRestore
    Status                                 : Failed
    StatusDetail                           : FailedOther
    SyncStage                              : CopyingMessages
    Flags                                  : IntraOrg, Pull, Suspend
    RequestStyle                           : IntraOrg
    Direction                              : Pull
    Protect                                : False
    Priority                               : Normal
    WorkloadType                           : Local
    Suspend                                : True
    SourceExchangeGuid                     : f35944e6-7575-4ed2-a243-0a2baabc907e
    SourceRootFolder                       :
    SourceVersion                          : Version 15.0 (Build 1293.0)
    SourceDatabase                         : RecoveryDB
    SourceServer                           : MAIL.regcon.local
    MailboxRestoreFlags                    : Recovery
    TargetAlias                            : viktoria
    TargetIsArchive                        : False
    TargetExchangeGuid                     : f35944e6-7575-4ed2-a243-0a2baabc907e
    TargetRootFolder                       :
    TargetVersion                          : Version 15.0 (Build 1293.0)
    TargetDatabase                         : DB1
    TargetServer                           : MAIL.regcon.local
    TargetMailboxIdentity                  : regcon.local/Users/UsernameVik
    IncludeFolders                         : {}
    ExcludeFolders                         : {}
    ExcludeDumpster                        : False
    ConflictResolutionOption               : KeepSourceItem
    AssociatedMessagesCopyOption           : Copy
    BatchName                              :
    BadItemLimit                           : 0
    BadItemsEncountered                    : 0
    LargeItemLimit                         : 0
    LargeItemsEncountered                  : 2
    QueuedTimestamp                        : 14.06.2017 23:57:09
    StartTimestamp                         : 14.06.2017 23:57:13
    LastUpdateTimestamp                    : 15.06.2017 0:00:39
    CompletionTimestamp                    :
    SuspendedTimestamp                     :
    OverallDuration                        : 15:50:01.6618480
    TotalSuspendedDuration                 : 00:00:00
    TotalFailedDuration                    : 15:46:31.4470288
    TotalQueuedDuration                    : 00:00:04.0557920
    TotalInProgressDuration                : 00:03:26.1590272
    TotalStalledDueToCIDuration            : 00:00:00
    TotalStalledDueToHADuration            : 00:00:00
    TotalStalledDueToMailboxLockedDuration : 00:00:00
    TotalStalledDueToReadThrottle          : 00:00:00
    TotalStalledDueToWriteThrottle         : 00:00:00
    TotalStalledDueToReadCpu               : 00:00:00
    TotalStalledDueToWriteCpu              : 00:00:00
    TotalStalledDueToReadUnknown           : 00:00:00
    TotalStalledDueToWriteUnknown          : 00:00:00
    TotalTransientFailureDuration          : 00:00:00
    TotalIdleDuration                      : 00:00:00.2495872
    MRSServerName                          :
    EstimatedTransferSize                  : 739.7 MB (775,615,213 bytes)
    EstimatedTransferItemCount             : 1675
    BytesTransferred                       : 920.6 MB (965,348,967 bytes)
    BytesTransferredPerMinute              : 0 B (0 bytes)
    ItemsTransferred                       : 1675
    PercentComplete                        : 100
    CompletedRequestAgeLimit               : 30.00:00:00
    PositionInQueue                        :
    InternalFlags                          : None
    FailureCode                            : -2146233088
    FailureType                            : TooManyLargeItemsPermanentException
    FailureSide                            :
    Message                                : Ошибка: В данном почтовом ящике превышено максимальное число больших элементов
                                             , указанных для этого запроса.
    FailureTimestamp                       : 15.06.2017 0:00:39
    IsValid                                : True
    ValidationMessage                      :
    OrganizationId                         :
    RequestGuid                            : f96d4f7b-bd46-4803-a6ff-a1b145152e0a
    RequestQueue                           : DB1
    Identity                               : ce9540f6-6de5-44d6-b33d-ad98fa6de043\f96d4f7b-bd46-4803-a6ff-a1b145152e0a
    DiagnosticInfo                         :
    Report                                 :
    ObjectState                            : New


    =STAS=

    • Изменено -STAS- 15 июня 2017 г. 12:57
    15 июня 2017 г. 12:54
  • У меня 20 МБ стоит. Больше сервер не выдерживает - при рассылке начинаются тормоза.

    HealthMailbox не восстаавливается никак пока ...


    =STAS=

    15 июня 2017 г. 13:39
  • >>HealthMailbox не восстаавливается никак пока ...

    почитайте вот: http://port25guy.com/2015/11/17/health-mailboxes-not-being-created-in-exchange-2013-exchange-2016/

    >>У меня 20 МБ стоит. Больше сервер не выдерживает - при рассылке начинаются тормоза.ну вот на время восстановления нужно сделать как указал Артем Set-Mailbox ящик -Maxreceivesize 999MB, а затем вернуть назад, ну или надо было запускать New-MailboxRestoreRequest с ключом -LargeItemLimit


    MCSAnykey

    15 июня 2017 г. 15:00
  • Ах, теперь Healthbox там ? Я просто смотрел в AD-Users - они там раньше были. Просто, как написано, с CU1 они переехали в поддиректорию Exchange. Тогда всё нормально, там их вижу.

    Ну вот, большинство проблем решили совместными усилиями !

    Большое спасибо вам, большие спецы по Exchange, а то я бы сам не разобрался ! В интернете информации много, но одни говорят так, другие этак, не стандартизировано всё так.

    Правда, пока ещё сервер не запускал (вернее, просто отключил временно сетевуху). Теперь осталось докопировать ящики и можно попробовать включить. Ой, чо будет ... Правда, так и не решили вопрос с Exchange Tools ... Переустанавливать учётку доменного админа как-то не хочется ...

    В общем, должен я вам по штуке каждому минимум :)


    =STAS=

    • Изменено -STAS- 15 июня 2017 г. 15:47
    15 июня 2017 г. 15:45
  • Ещё пару вопросов, если позволите:

    1. Как теперь подключить архивы к пользователям (они находятся в ещё невоссстановленой базе Archive). Можено ли через ECP каждому пользователю отключить архивацию, а потом включить, указав на новую базу и залив туда в его архивный ящик данные из старого архива.

    2. Что теперь делать с ненужными файлами и базами ? У меня теперь числится 1 нормальная база, две ломаные и одна база восстановления, с которой я уже всё слил. Я тут посмотрел в директория с новой базой DB1 - там почему-то оказалась ещё и старая база Mailbox Database 03....чего-то там, и ещё сотня с гаком тысяч файлов каких-то ! Как это всё почистить ?


    =STAS=

    16 июня 2017 г. 13:03
  • 1. Отключив архив и указав на новую базу вы просто создадите новый ящик в ней (пустой, как выше было через set-mailbox -database db1). Можете сделать так, а потом снова через recovery database восстановить содержимое ящиков в эти новые пустые ящики, в общем, все как вы проделали выше. Я бы пытался восстановить все это дело подменой edb, как уже писал ранее, в таком случае оно вероятно сразу заведется с живыми ящиками. Но вы новые рекомендации выполняете в странной последовательности, так, что потом леса рушатся, поэтому лучше по старинке, наверное:)

    https://blogs.msdn.microsoft.com/dvespa/2011/08/10/recovering-personal-archive-mailboxes-from-a-recovery-database/

    https://eightwone.com/2011/01/07/restoring-personal-archives/

    2. Очевидно же все вроде. Ломаные базы удалить, rdb удалить, ненужные файлы удалить, а если вы в рабочей папке базы устроили содомию и навалили туда вагон ненужных файлов - ну, не трогайте их и смиритесь с их существованием, например. Ну или разбирайте, вычищайте ненужные файлы и удаляйте.


    MCSAnykey

    16 июня 2017 г. 13:35
  • Ясно, спасибо !

    По первому пункту - ну не могу я так, КД восстановлен на 11.2015, а база на 06.2017 - кто из пользователей пришёл, кто ушёл .. никто уже не помнит. Приаттачу новую базу к старым данным и начнётся чехарда - тех пользователей нет, у этих имя поменялось, у кого-то - учётка и т.д. Лучше "по-старинке", тем более, способ проверенный :)

    2. вот ещё бы знать, какие файлы нужные, какие нет, а какие вообще от старой базы ... Может, ещё разок в другую, новую базу прыгнуть ? :):):) И там всё с чистАго листа :) Главное, чтобы к базе что-нибудь из существующего конфига не было привязано, а то так удалю базу и понесутся глюки в Exchange - какие-нибудь сертификаты там были привязаны, окажется, какие-то записи живые ... А если новую базу создавать, надо ставить галочку "возможность перезаписи данных" ?


    =STAS=


    • Изменено -STAS- 16 июня 2017 г. 13:54
    16 июня 2017 г. 13:50
  • >>вот ещё бы знать, какие файлы нужные, какие нет, а какие вообще от старой базы ... Может, ещё разок в другую, новую базу прыгнуть

    Знать не сложно, но это самый простой вариант, кстати. Поднимаете новую базу и простым мувреквестом перемещаете все ящики в новую, а потом удаляете старье, да.


    MCSAnykey

    16 июня 2017 г. 13:53
  • А там всякие системные ящики, какие-нибудь записи .. ещё какие подводные камни не возникнут ? И что за мувреквест на целую базу ? Или по-одному через EAC ?

    PS. Извините, замучал вас, наверно, просто первый раз восстанавливаю ... впредь буду умнее, особенно насчёт AD ;)

    P.S.: Сделал, как вы сказали - перенёс всех пользователей в новую базу, системные ящики пересоздал - и, о чудо ! - опять, в уже новой директории с базой 121 000 файлов ! Откуда они берутся в таком диком количестве ? И ещё w3p...exe начал есть много памяти и процессорного времени - постоянно что-то делает, чем-то занят ... раньше такого не было.


    =STAS=

    • Изменено -STAS- 17 июня 2017 г. 1:27
    16 июня 2017 г. 14:01
  • Всё, новую базу создал, всех туда переместил, системные ящики пересоздал на новой базе, разрешения прописал и старую отключил и удалил. В новой сделал циклическое обслуживание, чтобы файлы не плодились в диком количестве. Сейчас переношу логи.

    =STAS=

    19 июня 2017 г. 9:16