Изменения межсайтового подключения клиентского доступа RPC

Artigo
06/25/2012

Исходная статья опубликована 30 мая 2012 г.

Около двух лет назад я представил сеанс Разработка решений высокой доступности на конференции TechEd North America 2010. Во время этого сеанса я описал изменения над которыми мы работали и которые касались подключения через MAPI после перемещения почтового ящика и событий *over межсайтовой базы данных. К сожалению, после моей презентации нам пришлось сократить функциональность из-за сложности изменений, необходимых для ее введения, и недостатка времени на тестирование перед выпуском пакета обновления 1. И хотя я приложил все усилия, чтобы повысить приоритет этой работы, мы не смогли представить эти изменения и в пакете обновления 2.

К сожалению, не каждый компонент можно реализовать с хирургической точностью и некоторые изменения кода фактически остались в SP1. Например, вы могли заметить, что командлет Set-DatabaseAvailabilityGroup имеет свойство AllowCrossSiteRPCClientAccess. Этому логическому свойству можно присваивать допустимые значения, но они не повлияют на поведение в программе (вот почему мне кажется, что этот рисунок, как ни странно, уместен):

Поведение межсайтового подключения клиентского доступа RPC (RTM, SP1, SP2 до SP2-RU2)

Но я отвлекся. Давайте начнем с основ.

В Exchange 2010 главное изменение касалось способа подключения и доступа клиентов к данным, относящимся к почтовому ящику. В отличие от предыдущих версий клиенты больше не подключаются непосредственно к банку данных в роли сервера почтовых ящиков для доступа к данным почтового ящика. Вместо этого клиенты подключаются к набору служб в роли сервера клиентского доступа (CAS), а службы роли CAS получают доступ к данным почтового ящика через MAPI/RPC с сервера почтовых ящиков от имени подключающегося пользователя. Считайте, что это уровень абстракции.

По существу, было сделано одно простое изменение: все подключения MAPI, связанные с почтовым ящиком, осуществляются через службу клиентского доступа RPC в роли сервера клиентского доступа. Для упрощения этого уровня абстракции были изменены объекты базы данных, которые перестали быть дочерними объектами серверов почтовых ящиков. В базу данных почтовых ящиков было добавлено новое свойство RPCClientAccessServer, определяющее объект legacyExchangeDN, который должен использоваться для доступа к конкретной базе данных. Это свойство получает в качестве значения полное доменное имя. Чтобы обеспечить высокую доступность и отказоустойчивость в случае сбоя CAS, это значение должно быть полным доменным именем массива CAS с балансировкой нагрузки. Это полное доменное имя с балансировкой нагрузки мы называем массивом сервера клиентского доступа RPC.

Дополнительные сведения см. в статьях Брайана Дэя (Brian Day), посвященных объекту массива CAS: часть 1 и часть 2.

Типовое взаимодействие Outlook

Поведение всех версий Outlook однотипно в сценарии с одним центром обработки данных (или одним сайтом Active Directory). Конечная точка RPC профиля Outlook — это массив сервера клиентского доступа RPC (или отдельный CAS, если по каким-то причинам вы не создали массив; если вы не знаете, как это сделать — читайте статьи Брайана). При возникновении сбоя в DAG (ошибки базы данных, отказа сервера и т. д.) конечная точка RPC не изменяется, поэтому Outlook продолжает подключаться к тому же массиву сервера клиентского доступа RPC. При возникновении сбоя в массиве CAS (ошибки CAS, ошибки службы балансировки нагрузки и т. д.) конечная точка RPC не изменяется, поэтому Outlook продолжит подключаться к массиву сервера клиентского доступа RPC.

Поведение всех версий Outlook будет однотипным и в сценарии с переключением центра обработки данных, если следовать нашим инструкциям. Почему? При переключении центра обработки данных вы изменяете IP-адрес записи DNS массива сервера клиентского доступа RPC основного центра обработки данных на IP-адрес массива резервного центра. Служба автообнаружения продолжает воспринимать массив сервера клиентского доступа RPC основного центра обработки данных в качестве конечной точки RPC. Существующим клиентам Outlook не требуется изменение конфигурации; после обновления кэша DNS клиент просто подключается к конечной точке, которая теперь находится в резервном центре обработки данных. Чтобы полностью уяснить как это работает, нужно понять, что ни для клиента, ни для CAS на самом деле не важно, на каком сайте находится CAS. Важно только то, что клиент может подключиться к CAS, который может предоставить ему доступ к почтовому ящику.

Поведение *over межсайтовой базы данных

Для понимания этого сценария важно уяснить, что при настройке многосайтовой группы обеспечения доступности баз данных (DAG) свойство RPCClientAccessServer заданной базы данных обычно связывается с массивом сервера клиентского доступа RPC, который находится на том же сайте AD, что и копия базы данных почтовых ящиков с наименьшим предпочтительным числом активации. Например:

Рис. 1. Группа обеспечения доступности баз данных, распределенная между двумя сайтами Active Directory

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

Рис. 2. База данных MDB1 активирована на резервном сайте Active Directory

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

2012-05-06T15:44:29.001Z,67,112,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SFPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,0,00:00:00.0468822,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 5/6/2012 3:43:23 PM, currently Mounted; LogonId: 5",

Если массив сервера клиентского доступа RPC на сайте AD, на котором находится база данных почтовых ящиков с наименьшим предпочтительным значением активации, становится недоступным для пользователей, клиенты Outlook не смогут подключиться к своим почтовым ящикам, которые находятся в противоположном центре обработки данных. Другими словами, происходит сбой центра обработки данных и должен быть выполнен процесс переключения.

Проще говоря, Outlook всегда подключается к настроенной конечной точке RPC (если она доступна), независимо от значения свойства RPCClientAccessServer базы данных.

Может ли система изменить значение RPCClientAccessServer автоматически?

Система изменяет значение RPCClientAccessServer в базе данных только тогда, когда администратор изменяет число ActivationPreference в активированной копии базы данных на наименьшее значение (т. е. она становится предпочтительной копией), как показано на рис. 3.

Рис. 3. База данных MDB1 активирована на резервном сайте Active Directory и свойство RPCClientAccessServer изменено

Однако клиенты Outlook с существующим профилем Outlook продолжат использовать старую конечную точку RPC (даже если служба автообнаружения определила изменение). Это происходит потому, что старая конечная точка RPC не возвращает клиенту ответ ecWrongServer. Конечная точка RPC принимает подключение, поэтому Outlook игнорирует ответ службы автообнаружения, так как рабочее подключение уже имеется. Если старая конечная точка RPC становится недоступной, Outlook 2007/2010 обновит свои настройки (в отличие от Outlook 2003, который не использует службу автообнаружения). Вы можете в любой момент заставить Outlook использовать новую конечную точку RPC, если инициируете восстановление профилей.

Что происходит, если администратор вручную обновляет значение RPCClientAccessServer после события *over межсайтовой базы данных?

Вернемся к рисунку 2: если администратор вручную обновляет значение RPCClientAccessServer, чтобы оно указывало на cas-sec.contoso.com для MDB1 после активации копии базы данных почтовых ящиков в MBX-C (у которой значение ActivationPreference больше 1), то клиенты Outlook с существующим профилем продолжат использовать старую конечную точку RPC, пока она остается доступной (восстановление профилей устранит эту проблему). Профили Outlook, созданные после изменения значения RPCClientAccessServer, будут использовать новую конечную точку RPC.

Перемещение почтовых ящиков между сайтами Active Directory

До версии Exchange 2010 при перемещении почтовых ящиков между серверами конечная точка RPC Outlook должна была обновляться, чтобы указывать на сервер почтовых ящиков (или кластеризованный экземпляр сервера почтовых ящиков), размещающий базу данных, в которой находится почтовый ящик. После перемещения почтового ящика пользователь клиента Outlook получал сообщение "Администратор сервера Microsoft Exchange внес изменение, поэтому необходимо выйти из программы Outlook и перезапустить ее". После перезапуска Outlook клиент должен был подключиться к новой конечной точке RPC.

Как вы могли заметить, в Exchange 2010 при перемещении почтовых ящиков между сайтами AD пользователи не получают это сообщение. Кроме того, вы могли заметить, что конечная точка RPC не обновляется, чтобы указать массив сервера клиентского доступа RPC, связанный с базой данных почтовых ящиков на сайте AD, на котором теперь находится почтовый ящик. Это объясняется тем, что старая конечная точка RPC не возвращает клиенту ответ ecWrongServer. Конечная точка RPC принимает подключение, поэтому Outlook игнорирует ответ службы автообнаружения, так как рабочее подключение уже имеется. Если старая конечная точка RPC становится недоступной, Outlook обновит свои настройки (в отличие от Outlook 2003, который не использует службу автообнаружения). Вы можете в любой момент заставить Outlook использовать новую конечную точку RPC, если инициируете восстановление профилей.

Теперь я уверен, что вы понимаете рисунок, приведенный выше.

Будущее…SP2 RU3 и дальше

Я никогда не терял надежду решить эти проблемы. Это было непросто, но группа разработки клиентского доступа RPC, группа обслуживания Exchange и я неутомимо работали над необходимыми изменениями. Первая проблема — исправление профиля Outlook при перемещении почтового ящика между базами данных на разных сайтах AD. Вторая проблема — когда событие *over межсайтовой базы данных приводит к использованию CAS в Outlook, что не является самым оптимальным выбором для расположения текущей активированной базы данных.

Перемещение почтовых ящиков

По умолчанию после установки SP2 RU3 при перемещении почтовых ящиков между сайтами AD все версии Outlook предложат перезапустить программу и конечная точка RPC профиля Outlook будет обновлена.

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

2012-05-06T14:43:03.875Z,37,1,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156267,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb2 last mounted on MBX-C.contoso.com at 5/5/2012 9:44:05 PM, currently Mounted; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

Обратите внимание, что операция RPC (ROP) — это WrongServer (также называемая ecWrongServer). Она заставляет клиент Outlook запустить обнаружение профилей и обновить профиль в соответствии с новыми данными, найденными в каталоге. Профиль обновляется, и после перезапуска клиент устанавливает соединения с новой конечной точкой RPC.

Сразу отвечу на вопрос, при каких еще условиях вы будете получать сообщение "Администратор сервера Microsoft Exchange внес изменение, поэтому необходимо выйти из программы Outlook и перезапустить ее".

При указании свойства DoNotPreserveMailboxSignature в New-MoveRequest.
Если исходная и конечная базы данных почтовых ящиков имеют разные хранилища иерархии общедоступных папок.
При перемещении почтового ящика из устаревшей версии Exchange в Exchange 2010.

События *over межсайтовой базы данных

Поведение при событии *over межсайтовой базы данных будет зависеть от значения свойства DAG AllowCrossSiteRPCClientAccess. Если свойству AllowCrossSiteRPCClientAccess присвоить значение $true, то поведение, которое я описал в предыдущем разделе, будет поведением по умолчанию — при активации базы данных в резервном центре обработки данных пользователи продолжат использовать в качестве конечной точки подключения массив клиентского доступа RPC на сайте AD, на котором находится база данных почтовых ящиков с наименьшим предпочтительным значением активации.

Если свойству AllowCrossSiteRPCClientAccess присвоить значение $false ($false — значение этого свойства по умолчанию), то конечная точка RPC профиля Outlook обновится и будет указывать на массив сервера клиентского доступа RPC, который находится на том же сайте AD, на котором база данных активна и подключена. Обратите внимание, что свойство RPCClientAccessServer не обновляется, так как оно определяет предпочтительный сайт.

Рис. 4. База данных MDB1 активирована на резервном сайте Active Directory и профиль Outlook обновился автоматически

2012-05-06T15:12:42.958Z,47,7,/o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded,,OUTLOOK.EXE,14.0.6025.1000,Classic,,,ncacn_ip_tcp,,OwnerLogon,1144 (rop::WrongServer),00:00:00.0156262,"Logon: Owner, /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=userded in database mdb1 last mounted on MBX-C.contoso.com at 3/6/2012 2:59:30 PM, currently InTransitSameSite; Redirected: this server is not in a preferred site for the database, suggested new server: /o=E2010/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=cas-sec.contoso.com",RopHandler: Logon:

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

Заключение

Итак, начиная с выпуска SP2 RU3 вы можете быть уверены, что профили почтовых ящиков, перемещенных между сайтами AD, будут обновляться правильно. Кроме того, в сценарии *-over межсайтовой базы данных вы можете разрешить межсайтовое подключение RPC или заставить клиент Outlook использовать массив сервера клиентского доступа RPC, который находится на том же сайте AD, на котором находится активированная и подключенная база данных (поведение по умолчанию). Мне кажется, что эту статью можно завершить такой картинкой:

Росс Смит IV (Ross Smith IV)
старший руководитель программы
группа улучшения качества программного обеспечения Exchange

Это локализованная запись блога. Исходная статья доступна по адресу: RPC Client Access Cross-Site Connectivity Changes

Compartilhar via