А при попытке зайти в Exchange Management Shell выдавалось сообщение типа «The attempt to connect to http://<Exchange FQDN>/powershell using ‘Kerberos’ authentication failed». В Интернете можно найти такие варианты решения проблемы:

1. удостовериться, что часы на сервере синхронизированы с контроллером домена (в моем случае все в порядке)
2. воспользоваться скриптом EMTshooter.ps1 от Microsoft (не помогло)
3. удалить значение в реестре командой (снова не помогло)

Remove-ItemProperty -Path HKCU:\Software\Microsoft\ExchangeServer\v14\AdminTools\ -Name NodeStructureSettings

4. рестартовать службу World Wide Publishing (ну или как вариант вообще весь сервер, все равно не помогло)

В моем случае проблема оказалась в SPN, добавленном в процессе настройки NDES на том же сервере, что и Exchange:

После удаления «лишнего» SPN проблема с Exchange Management Tools исчезла:

setspn -D http/bar-exchange.bar.local BAR\ndes.service

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

1. запускаем оснастку Active Directory Users and Computers
2. включаем в меню «Вид»  пункт «Дополнительные компоненты», если он не включен
3. заходим в свойства почтового ящика, доступ к которому нужно убрать, и переходим на вкладку «Редактор атрибутов»
4. находим атрибут msExchDelegateListLink и удаляем из него пользователя, у которого нужно забрать доступ:

После перезапуска Outlook немного подумает и таки удалит  ненужный ящик из области навигации.

Однако, процедура получения сертификата, импорта его в системное хранилище и затем выбора этого сертификата в iPCU может показаться утомительной (особенно последний пункт, поиск сертификата в списке установленных доставляет кучу удовольствия). Процесс можно автоматизировать, используя SCEP, благо IOS его поддерживает начиная с версии 4. Добавляем в профиль конфигурации настройки SCEP, и при правильной настройке сервера устройство получит сертификат сразу в процессе установки профиля. Стоит отметить, что сертификат должен иметь расширение «авторизация клиента», иначе авторизация на сервере не пройдет (если в качестве сервера SCEP используется Microsoft NDES, то шаблон сертификата, используемый по умолчанию, не подходит). Однако тут возникает вопрос: как указать клиенту ActiveSync, что он должен использовать сертификат, полученный в результате запроса SCEP? Это нельзя сделать с помощью iPCU. Придется редактировать профиль вручную.

Итак, создаем профиль конфигурации, в который добавляем настройки Exchange ActiveSync (без сертификата клиента) и настройки запроса SCEP. Экспортируем этот профиль, не шифруя и не подписывая его. Открываем полученный файл с расширением .mobileconfig (это обычный xml, вполне читабельный) в текстовом редакторе и добавляем в секцию настроек Exchange ActiveSync ключ PayloadCertificateUUID со значением типа string, в котором указываем PayloadUUID секции настроек SCEP.  Теперь при установке профиля IOS будет знать, что клиент ActiveSync должен использовать сертификат, полученный в результате запроса SCEP.

Все, остается только установить полученный профиль конфигурации на устройство, и оно автоматом получит сертификат и будет использовать его для авторизации на сервере Exchange.

foreach ($device in (Get-ActiveSyncDevice `
     | where { $_.DeviceAccessStateReason -eq 'Upgrade' }))
{
  $allowedIds = @();
  $allowedIds += Get-CASMailbox $device.UserDisplayName `
    | select ActiveSyncAllowedDeviceIDs -ExpandProperty ActiveSyncAllowedDeviceIDs;
  if ($allowedIds) { $allowedIds += $device.DeviceId; }
  else { $allowedIds = $device.DeviceId; }
  Set-CASMailbox $device.UserDisplayName -ActiveSyncAllowedDeviceIDs $allowedIds;
}

Understanding Device Access States

powershell> New-ExchangeCertificate -GenerateRequest -SubjectName "dc=com,dc=contoso,cn=test-exchange.contoso.com" -DomainName test-exchange,test-exchange.contoso.com,autodiscover.contoso.com

2. Скармливаем вывод предыдущего шага форме advanced certificate request своему серверу сертификатов (https://<CA_server>.contoso.com/certsrv), шаблон сертификата – WebServer

3. Полученный сертификат в DER-формате (*.cer) сохраняем на диск, например, как c:\cert_exchange.cer, и импортируем в Exchange:

powershell> Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\cert_exchange.cer –Encoding byte))

4. Задействуем импортированный сертификат:

powershell> Enable-ExchangeCertificate -Thumbprint <...> -Services SMTP,POP,IMAP,IIS

1. Запускаем Exchange Management Shell и создаем группу хранения для восстановления данных (специальная Storage Group с флажком Recovery) где-нибудь в удобном месте (для примера пусть это будет папка c:\rsg):

[PS] C:\>New-StorageGroup RecoveryGroup -LogFolderPath c:\rsg -SystemFolderPath c:\rsg -Recovery

2. Копируем файлы из бэкапа в папку группы хранения:

[PS] C:\>xcopy /e rsg_orig rsg
rsg_orig\E00.chk
rsg_orig\E0000000001.log
...
rsg_orig\E0000000015.log
rsg_orig\E00res00001.jrs
rsg_orig\E00res00002.jrs
rsg_orig\E00tmp.log
rsg_orig\Mailbox Database.edb
rsg_orig\tmp.edb
rsg_orig\CatalogData-efe5b62a-623d-48af-b63e-d69e71941047-cc64dd2d-2428-4f12-bba2-79d6d34c4d27\00010001.ci
...
rsg_orig\CatalogData-efe5b62a-623d-48af-b63e-d69e71941047-cc64dd2d-2428-4f12-bba2-79d6d34c4d27\Used0000.002
55 File(s) copied

3. Подключаем восстановленную почтовую базу как базу для восстановления данных:

[PS] C:\>New-MailboxDatabase -MailboxDatabaseToRecover "Mailbox Database" -StorageGroup RecoveryGroup
WARNING: The recovery database 'Mailbox Database' was created using the
existing file: c:\rsg\Mailbox Database.edb. The database must be brought into a
clean shutdown state before it can be mounted.
WARNING: The recovery database 'Mailbox Database' was created using the
existing file: c:\rsg\Mailbox Database.edb. The database must be brought into a
clean shutdown state before it can be mounted.

Name Server StorageGroup Recovery
---- ------ ------------ --------
Mailbox Database TEST-EXCHANGE RecoveryGroup True

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

4. Переводим почтовую базу в clean shutdown state, о котором нас предупредили на предыдущем шаге, с помощью команды eseutil:

[PS] C:\>cd c:\rsg
[PS] C:\rsg>eseutil /r E00 /i /d
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.03
Copyright (C) Microsoft Corporation. All Rights Reserved.Initiating RECOVERY mode...
Logfile base name: E00
Log files: <current directory>
System files: <current directory>
Database Directory: <current directory>
Performing soft recovery...
Restore Status (% complete)
0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................
Operation completed successfully in 1.172 seconds.

Подробно об eseutil можно прочитать здесь:

http://technet.microsoft.com/ru-ru/library/bb123479(v=EXCHG.80).aspx

5. Можно монтировать восстановленную базу:

[PS] C:\rsg>Mount-Database "RecoveryGroup\Mailbox Database"

6.  Ну и наконец-то можно восстанавливать контакты для нашего пользователя (пусть будет aaron):

[PS] C:\rsg>Restore-Mailbox aaron -RSGDatabase "RecoveryGroup\Mailbox Database" -IncludeFolders \????????

Вместо знаков вопроса здесь должно быть слово «Контакты»

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

[PS] C:\rsg>DisMount-Database "RecoveryGroup\Mailbox Database"
[PS] C:\rsg>Remove-MailboxDatabase "RecoveryGroup\Mailbox Database"
[PS] C:\rsg>Remove-StorageGroup RecoveryGroup
[PS] C:\rsg>cd c:\
[PS] C:\>rmdir c:\rsg