Стандартная, вроде бы, ситуация с добавлением нового узла (из другого датацентра) в DAG вываливается ошибкой:

Error: An error occurred while attempting a cluster operation. Error: Cluster API
'"AddClusterNode() (MaxPercentage=12) failed with 0x35. Error: The network path was not found

DagTask ситуацию не особо проясняет:

[] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseValidateNodeState,
ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational,
dwPercentComplete = 12, szObjectName = MBX3, dwStatus = 0x0 )
[] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseValidateNodeState,
ePhaseType = ClusterSetupPhaseContinue, ePhaseSeverity = ClusterSetupPhaseFatal,
dwPercentComplete = 12, szObjectName = MBX3, dwStatus = 0x35 )
[] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseValidateNodeState,
ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseFatal,
dwPercentComplete = 12, szObjectName = MBX3, dwStatus = 0x35 )
[] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseFailureCleanup,
ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational,
dwPercentComplete = 12, szObjectName = MBX3, dwStatus = 0x0 )
[] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseFailureCleanup,
ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational,
dwPercentComplete = 12, szObjectName = , dwStatus = 0x0 )

[] The preceding log entry comes from a different process running on computer 'MBX2.domain.ru'
[] The operation wasn't successful because an error was encountered. You may find more
details in log file "C:ExchangeSetupLogsDagTasksdagtask____.log".
[] WriteError! Exception = Microsoft.Exchange.Cluster.Replay.DagTaskOperationFailedException:
A database availability group administrative operation failed. Error: The operation failed.
CreateCluster errors may result from incorrectly configured static addresses. Error:
An error occurred while attempting a cluster operation. Error: Cluster API '"AddClusterNode()
(MaxPercentage=12) failed with 0x35. Error: The network path was not found"' failed. --->
Microsoft.Exchange.Cluster.Replay.AmClusterApiException: An Active Manager operation failed.
Error An error occurred while attempting a cluster operation. Cluster API '"AddClusterNode()
(MaxPercentage=12) failed with 0x35. Error: The network path was not found"' failed.. --->
System.ComponentModel.Win32Exception: The network path was not found

Видно, что добавление в DAG прерывается на фазе проверки (eSetupPhase = ClusterSetupPhaseValidateNodeState). Ради интереса попробовал запустить проверку узлов из оснастки Failover Cluster. Проверка проходит.

Потом подумал на проблему с разным количеством сетевых интерфейсов на Primary Active Manager и новом узле DAG. В Planning for High Availability and Site Resilience явно не указано, что количество сетевых интерфейсов на всех узлах DAG должно быть одинаково. Однако, знающие люди сказали, что в DAG можно добавлять серверы с разным количеством сетевых интерфейсов, хотя, вроде бы, это и не поддерживаемая конфигурация.

Пришлось слушать трафик. Тут пошли более интересные результаты. например:

1027     ip2     ip3     SMB2     SMB2:C   TREE CONNECT (0x3), Path=\MBX3IPC$
1028     ip3     ip2     SMB2     SMB2:R   TREE CONNECT (0x3), TID=0x11
1029     ip2     ip3     SMB2     SMB2:C   IOCTL (0xb), FID=0xFFFFFFFFFFFFFFFF
1030     ip3     ip2     SMB2     SMB2:R  - NT Status: System - Error,
Code = (34) STATUS_ACCESS_DENIED  IOCTL (0xb)

PAM пытается подключиться к IPC$ на новом узле и получает ACCESS_DENIED. Согласно спецификации SMB3 запрос IOCTL, в котором содержится FID=0xFFFFFFFFFFFFFFFF фактически является запросом на согласование Security-диалектов между узлами перед разрешением SMB-сессии. Подробнее эта процедура описана тут. ACCESS_DENIED возвращается, в частности, когда сервер не может подтвердить запрос, и, скорее всего, это является следствием того, что возникла ошибка аутентификации.

Тут внезапно оказывается, что между датацентрами есть небольшое расхождение во времени (около минуты). Это быстро исправляют. Ошибка уходит…

Полезные ссылки:
SMB3 Secure Dialect Negotiation
Planning for High Availability and Site Resilience
[MS-SMB2]: Server Message Block (SMB) Protocol Versions 2 and 3

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

nlb-2nic

В этой схеме, начиная с Windows Server 2008 мы будем иметь следующее:

  • связь с кластерным ip-адресом из той же сети, где расположены узлы NLB, будет работать без каких-либо проблем
  • связь с кластерным ip-адресов из внешней сети (клиент обращается через маршрутизатор) будет отсутствовать
  • если мы переносим дефолтный шлюз с клиентского адаптера на кластерный, то связь с кластерным ip-адресом появляется

Внешний клиент пытается попасть на кластерный адаптер, но так как шлюза на нём не прописано, то пакет отбрасывается. Связано это с тем, что IP forwarding, включенный по умолчанию в Windows 2003 Server, позволявший отвечать клиенту через дефолтный шлюз, начиная с Windows Server 2008 выключен по умолчанию. А раз он выключен, то надо его включить. Например через netsh:

netsh interface ipv4 set interface "Cluster NIC" forwarding=enabled

или сразу через ключ в реестре:

Key name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value Name: IpEnableRouter
Data Type: REG_DWORD
Value: 1

Полезные ссылки:
Balancing Act: Dual-NIC Configuration with Windows Server 2008 NLB Clusters

e2010 В Exchange 2010 при удалении сообщений из почтового ящика пользователя сообщение фактически не удаляется, а перемещается в скрытую папку Recoverable Items. Письмо хранится в этой папке ещё некоторое время (по умолчанию 14 дней), после чего специальным ассистентом перемещается в другую скрытую папку Purge, откуда уже по возможности почтовым сервером письмо окончательно удаляется. Фактически, пользователь не имеет права ничего удалять из своего почтового ящика. Все операции, связанные с удалением производятся почтовой системой по истечении сроков хранения данных. Иногда это приводит к забавным случаям.

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

Get-Mailbox mailbox | Get-MailboxStatistics | fl TotalDeletedItemSize

TotalDeletedItemSize    : 30 GB

Стандартная квота на размер папки, в которую перемещаются сообщения после удаления пользователем составляет 30 Гб. При превышении этой квоты пользователь ничего не сможет удалить из почтового ящика, пока соответствующий ассистент на сервере не удалит сообщения с истёкшим временем хранения. Но есть лазейка для администратора – он может специальным командлетом почистить сообщения из папки Recoverable Items:

Search-Mailbox -Identity mailbox -SearchDumpsterOnly -DeleteContent

Ключ SearchDumpsterOnly говорит о том, что поиск производится только по Recoverable Items. Ключ DeleteContent указывает на необходимость удаления того, что найдено в Recoverable Items.

Для того, чтобы избежать повторения ситуации есть два способа – увеличить лимит на папку Recoverable Items, либо снизить время хранения в ней сообщений.

Первый вариант:

Set-Mailbox mailbox -RecoverableItemsQuota 50GB -UseDatabaseQuotaDefaults $false

Второй вариант (например, уменьшаем срок хранения до одного дня):

Set-Mailbox mailbox -UseDatabaseRetentionDefaults $false -RetainDeletedItemsFor 1.00:00:00 

Полезные ссылки:
Clean Up the Recoverable Items Folder
Understanding Recoverable Items

MVP_640x255

Картинка нажимабельна. Из спикеров заострю внимание на Олеге Крылове, который будет палить ТЗ привезённые с MEC 2014. Я, к сожалению, время проведения мероприятия упустил, так что Олег будет отдуваться там один.