Очередная встреча UC² под номером 26 состоится через две недели, 30 числа, как обычно с 18-00 до 21-00. Встреча будет проходить и в ОНЛАЙН-режиме. А вот кто будет выступать:

  • Михаил Переяславский, Инженер группы технической поддержки отдела продаж, Integrated Research UKI Ltd

Тема: Подходит ли ваша сеть для Skype for Business Online?

Подзаголовок: IR Prognosis UC Assessor.

Краткое содержание: Переход на облачные решения, как то Office 365 и, в частности, Skype For Business Online, накладывает определённые требования на сетевую инфраструктуру. Соответствует ли она этим требованиям?  Как IR Prognosis UC Assessor (Microsoft certified IT Pro Tool) поможет ответить на этот вопрос – об этом пойдёт речь на семинаре.

  • Александр Журавлев, Руководитель лаборатории, UCLAB

Тема доклада: Решения AudioCodes для Skype Operations Frameworks.

Краткое содержание: В докладе будет рассмотрена актуальная версия методологии Skype Operations Frameworks V4 (SOF) и будут рассмотрены решения AudioCodes (с практическими примерами и демонстрациями) и их роли в методологии SOF .

  • Mediant CCE Appliance (Skype for Business Cloud Connector Edition
  • IP Phones для Skype for Business / Skype for Business Online (Firmware 3.X)
  • IP Phone Manager

Регистрация на встречу как обычно тут.

Обновление: как доносит народная молва это поведение появилось в Exchange 2016 CU4. При отключении ящика не очищается аттрибут legacyExchangeDN. Заведён баг.

Ситуация: сотрудник переходит из одного подразделения в другое. На предыдущем месте работы он использовал линкованый ящик. На новом месте будет использовать обычный. Вроде бы штатная операция – необходимо отключить линкованый ящик (Disconnect-Mailbox) и подключить его к новой учётной записи (Connect-Mailbox). После очистки базы (Update-StoreMailboxState) получаем рабочий OWA и нерабочий Outlook. Профиль настраивается, но при запуске Outlook возвращается ошибка, что нет доступа к дереву папок. Картинка будет примерно такая:

В логе MAPI/HTTP на бэкэнде нашлась вот такая вот интересная запись:

MoMTException:2147746065 (rpc LoginFailure) -> [LoginFailureException] Unable to access AD 
(StoreError=LoginFailure) -> [StoragePermanentException] There was a problem accessing Active 
Directory. Check your network connections and try again. -> [ValueNotPresentException] 
Property 'IsSoftDeletedByRemove' is not present on object 'Some User Mailbox'.

В общем понятно, что ничего не понятно. Однако, беглый обзор аттрибутов двух учёток (новой, и старой от линкованого ящика) позволил обнаружить, что обе учётки имеют один и тот же аттрибут legacyExchangeDN. После очистки этого аттрибута на старой учётке Outlook сразу же запустился.

Аттрибут этот очень хитрый. Внутри Exchange использует именно его для маршрутизации почты. Поэтому его задвоение как миниму приводит к невозможности нормальной работы пострадавшего почтового ящика. Как оказывается он так же участвует и в процессе аутентификации.

Полезные ссылки:
Clean-MailboxDatabase in Exchange 2013
The Attribute, the Myth, the legacyExchangeDN

На текущий момент старые серверы с ролью mailbox не выполняют полезных функций: пользовательские данные перенесены в новые почтовые базы, OAB создаётся на новых серверах и клиенты используют уже её. Настало время выводить эти старые серверы из эксплуатации. Но прежде чем запускать установщик на удаление необходимо удалить со старых серверов следующее:

  • пустые базы почтовых ящиков
  • старую OAB
  • пустые базы общих папок

Удаляем пустые базы почтовых ящиков

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

Get-MailboxDatabase -Server oldserver | Remove-MailboxDatabase

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

Удаляем старую OAB

После миграции OAB на новые серверы ничто не мешает старую OAB удалить:

Remove-OfflineAddressBook 'Old Address Book'

Удаляем базы общих папок

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

MoveAllReplicas.ps1 -Server oldserver -NewServer newserver

Процесс переноса можно отслеживать по наличию локальных копий перемещаемых папок:

Get-PublicFolderStatistics -Server oldserver

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

Set-MailboxDatabase somedatabase -PublicFolderDatabase $null

И тут нам на помощь придёт утилита ADSIEdit. Необходимо будет подключиться к разделу конфигурации и в нужных базах, расположенных тут – CN=Services > CN=Microsoft Exchange > CN=(your organization name) > CN=Administrative Groups > CN=Exchange Administrative Group (FYDIBOHF23SPDLT) > CN=Databases очистить аттрибут msExchHomePublicMDB. Подробно процесс в картинках можно посмотреть тут.

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

Get-PublicFolderDatabase -Server oldserver | Remove-PublicFolderDatabase

Удаляем последнюю базу общих папок

Перед удалением последней базы общих папок чистим её от остатков папок:

Get-PublicFolder -Server newserver "\" -Recurse | Remove-PublicFolder -Recurse
Get-PublicFolder -Server newserver "\Non_Ipm_Subtree" -Recurse | Remove-PublicFolder -Recurse

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

  • Все папки оффлайновых адресных книг, расположенные в \Non_Ipm_Subtree\OFFLINE ADDRESS BOOK\
  • Папка \Internet Newsgroups

Согласно этой ссылке это “нормальное” и ожидаемое поведение. Существует небольшой финт ушами, который позволит эту проблему обойти. Для этого мы отключаем базу общих папок, удаляем всё содержимое папки, в которой хранятся файлы базы и монтируем базу назад. В итоге мы получаем девственно чистую базу без артефактов прошлых эпох. Так как старая база никаких ценных данных не содержала, то мы при этом процессе ничего не теряем. После этого последнюю базу общих папок можно удалять:

Remove-PublicFolderDatabase -Server newserver -RemoveLastAllowed

Ключ -RemoveLastAllowed обязателен.

Удаление mailbox-сервера

После того, как удалены все базы и OAB mailbox-сервер можно удалить либо через штатный GUI в Program and Files, либо через командную строку:

Setup.com /mode:Uninstall /role:M

Полезные ссылки:
How to Remove the Default Public Folder Database for an Exchange Mailbox Database
Unable to delete the OAB system folders in Exchange 2007?

Механизм создания и распространения оффлайновой адресной книги между версиями Exchange 2010 и Exchange 2016 сильно различается. Поэтому процесс переключения на OAB, находящийся на Exchange 2016, в процессе миграции нужно будет продумывать очень внимательно.

Старый механизм (Exchange 2010) работал следующим образом:

  1. Выделенный сервер с ролью mailbox по расписанию генерировал файлы OAB
  2. После создания обновлённой OAB она скачивалась на серверы с ролью Client Access Server в веб-директории
  3. Клиент Outlook обращался в эти веб-директории (её адрес он получал от службы автообнаружения) и скачивал локально файлы OAB

Подробнее процесс описан тут.

Новый механизм (Exchange 2013/2016) работает так:

  1. Специальный робот OABGeneratorAssistant генерирует OAB на сервере, где находится активная база со специальным арбитражным ящиком. У специального арбитражного ящика должна быть включена функция OrganizationCapabilityOABGen. По умолчанию она включена в ящике SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}
  2. Затем сгенерированная OAB выгружается в веб-директорию на этом же сервере
  3. Клиент Outlook обращается в эту веб-директории (её адрес он получает от службы автообнаружения) и скачивает локально файлы OAB

Подробно процесс описан тут.

В процессе миграции OAB есть одна тонкость – мы OAB не мигрируем. Мы клиентов переключаем на новый OAB, которая генерируется по новой схеме. Схема миграции будет выглядеть примерно следующим образом:

  • Создаём отдельный арбитражный ящик и включаем в нём функцию OrganizationCapabilityOABGen (делать это необязательно, так как у нас имеется ящик SystemMailbox{bb558c35-97f1-4cb9-8ff7-d53741dc928c}, который можно использовать для этих целей):
New-Mailbox -Arbitration -Name "OAB Mailbox" -Database db1 -UserPrincipalName oab@o365lab.pro
Set-Mailbox -Arbitration oab -OABGen $true
  • Создаём новую OAB и копируем в неё адресные списки из старой OAB:
$OAB = Get-OfflineAddressBook 'Old Address Book'
New-OfflineAddressBook -Name "New Address Book (Ex2016)" -AddressLists $OAB.AddressLists
  • Привязываем новую OAB к новому арбитражному ящику, который будет заниматься генерацией OAB:
$mbx = Get-Mailbox 'OAB Mailbox' -Arbitration
Set-OfflineAddressBook 'New Address Book (Ex2016)' -GeneratingMailbox $mbx.Identity
  • Имеет смысл включить GlobalWebDistributionEnabled и ShadowMailboxDistributionEnabled (что это такое можно посмотреть тут)
Set-OfflineAddressBook "New Address Book (Ex2016)" -VirtualDirectories $null 
-GlobalWebDistributionEnabled $true -ShadowMailboxDistributionEnabled $true
  • Запускаем обновление OAB и переназначаем её всем базам:
Update-OfflineAddressBook 'New Address Book (Ex2016)'
Get-MailboxDatabase | Set-MailboxDatabase -OfflineAddressBook 'New Address Book (Ex2016)'

На выходе мы получаем новую OAB, которая создаётся на серверах Exchange 2016 и которую используют все ящики, которые смигрировали на Exchange 2016.

Полезные ссылки:
Understanding Offline Address Books (Exchange 2010)
Offline address books in Exchange 2016
OAB Improvements in Exchange 2013 Cumulative Update 7
OAB Improvements in Exchange 2013 Cumulative Update 5
OAB in Exchange Server 2013
Managing OAB in Exchange Server 2013