Меню

Ошибка создания кластера ошибка операции администрирования

Автор Rasty, 23 ноя 2015, 14:21

0 Пользователей и 1 гость просматривают эту тему.

Ошибка получение списка кластеров:
Ошибка операции администрирования
1с не найдено ни одного сервера с размещенным сервисом serviceName=ClusterConfigService.

Типичная ситуация, пришел с утра, открываю консоль, хренак и на, в интернетах ничего дельного не нашел кроме этого
Самое интересное пользователи работают…

WTF?

Помогли — Скажи спасибо! Решил сам — поделись решением!
:)


Останавливаем 1с сервак, сносим все что в папке C:Program Files (или x86)1cv8srvinfo, запускаем сервак, добавляем базы, и все работает.

Помогли — Скажи спасибо! Решил сам — поделись решением!
:)


Цитата: Rasty от 24 ноя 2015, 14:56
Останавливаем 1с сервак, сносим все что в папке C:Program Files (или x86)1cv8srvinfo, запускаем сервак, добавляем базы, и все работает.

Спасибо, столкнулся с такой же проблемой, и описанное решение помогло.



А если это не помогает? удаляешь, добавляешь снова базу и при запуске 1с тоже самое :(
Проблема с лицензией может быть или нет?


нужно на сервере через администрирование удалить все процессы и добавить заново.

Спасибо за Сказать спасибо


Цитата: alex0402 от 22 авг 2017, 21:23
нужно на сервере через администрирование удалить все процессы и добавить заново.

Какие процессы? я сервак 1с останавливаю на сервере и все из каталога удаляю, там в итоге пусто.
Перегружаю весь комп-сервер.
Потом запускаю сервер 1с и добавляю базу снова в админке 1с.
Потом запускаю 1с и пытаюсь подключится и в итоге тоже самое :(


Нужно дать полные права юзеру usrv8 на все внутренности папки srvinfo


Цитата: Вовчик от 08 дек 2016, 08:17

Цитата: Aleksh_kz от 16 сен 2016, 10:56

Цитата: Rasty от 24 ноя 2015, 14:56
Останавливаем 1с сервак, сносим все что в папке C:Program Files (или x86)1cv8srvinfo, запускаем сервак, добавляем базы, и все работает.

Спасибо, столкнулся с такой же проблемой, и описанное решение помогло.

)))) а есть адекватное решение?

Не обязательно удалять всю папку srvinfo, достаточно удалить только папки, начинающиеся с snccntx, т е содержащие сессионные данные. Такой способ полезен, если у тебя овердохера баз и одно только добавление их по новой трудоёмко.


Цитата: iphr от 20 дек 2017, 16:58
Нужно дать полные права юзеру usrv8 на все внутренности папки srvinfo

Какие права, о чем ты? просто поменяй порт подключения клиентов… все B)


   Garry1010

27.11.20 — 15:40

Вдруг ни с того, ни с сего 1С выдала: ошибка формата потока (хорошо, база тестовая, но разработачная). Причём, выдала не при входе в базу, а при сохранении конфы при разработке.О_О НИКОГДА такого не видел!

База клиент-серверная на MS SQL — так что никакие chdbfl.exe или Tool_1CD.exe не помогут.

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

Попробовал выгрузить бэкап средствами SQL и загрузить снова в другую базу. При попытке подключения базы в консоли кластера 1С имеем: «Ошибка создания информационной базы: ошибка операции администрирования ошибка формата потока» (О_О никогда такого не видел).

ГуглоЯндекс выдаёт только стандартные ответы — без толку. Понятно, что что-то грохнулось в самой конфе: нехило так грохнулось — это ж умудриться надо так сломать конфу ;).

Вопрос: кто-то сталкивался с таким? Это лечится? Если лечится, то чем и как?

Не хочется потерять наработки, которые не успел скинуть в хранилище — хотел вечером в рабочую накатить, а теперь нечего накатывать, блин…:(

   arsik

1 — 27.11.20 — 15:41

Жопа рисуется по другому

(_!_)

   dka80

2 — 27.11.20 — 15:44

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

   shuhard

3 — 27.11.20 — 15:44

(0)[Не хочется потерять наработки, которые не успел скинуть в хранилище]

копируй средствами сиквела в заведомо живую базу

   Garry1010

4 — 27.11.20 — 15:50

(3) Копировать — что?

   shuhard

5 — 27.11.20 — 15:54

(4) конфигурацию базы данных, ты же за неё борешься ?

   Salimbek

6 — 27.11.20 — 16:01

(4) Тут вот написано: https://its.1c.ru/db/metod8dev/content/1591/hdoc

«Вся информационная база представляется в базе данных в виде набора таблиц. Среди них есть несколько таблиц, которые обязательно присутствуют в представлении любой информационной базы:

    Config — основная конфигурация информационной базы. Эта конфигурация соответствует реальной структуре данных и используется 1С:Предприятием 8.0 в режиме Предприятия.

    ConfigSave — конфигурация, редактируемая Конфигуратором. Конфигурация из ConfigSave переписывается в Config при выполнении «Обновления конфигурации базы данных» в Конфигураторе, а наоборот — при выполнении в Конфигураторе операции «Конфигурация — Конфигурация базы данных — Вернуться к конфигурации БД». «

   fisher

7 — 27.11.20 — 16:03

Ну, первым делом стоит прогнать dbcc checkdb

Если сиквел ошибок не покажет, тогда это одинэсный «самострел». Сталкивался с таким, когда последствия динамических обновлений приходились на Юпитер в седьмом доме Водолея.

Можно найти руководства разной степени полезности по ручному ковырянию в Config и ConfigSave. Мне когда-то помогло. С тех пор пару раз сильно выручало наличие хранилища конфигурации.

   Ненавижу 1С

8 — 27.11.20 — 16:09

службу останавливали и дождались завершение процесса, кеш чистили на сервере?

   arsik

9 — 27.11.20 — 16:20

(4) Сначала почисти ConfigSave, если не поможет перенеси из ConfigSave в Config. Если снова не поможет ковыряй Config.

   Garry1010

10 — 27.11.20 — 16:23

(6) Это-то понятно. Но там нет исправления ошибок.

(8) Да, чистил.

(9) Почистить — это как? Не понял…

   arsik

11 — 27.11.20 — 16:27

(10) В таблице ConfigSave строки есть?

   Garry1010

12 — 27.11.20 — 16:51

(7) «Command(s) completed successfully.» 🙂 -_о

(11) Шесть (6) строк есть.

   arsik

13 — 27.11.20 — 16:56

Удали их

   Garry1010

14 — 27.11.20 — 16:58

(13) А как потом жить? Она же пустая будет, кяп?

   arsik

15 — 27.11.20 — 16:59

Ну у тебя же бэкап есть. Она должна быть пустая.

   arsik

16 — 27.11.20 — 17:01

Там хранится изменения после сохранения но до обновления.

   arsik

17 — 27.11.20 — 17:17

если не поможет перенеси из ConfigSave в Config — вот это наверно не надо.

Покажи что выдает запрос

SELECT * FROM public.config

ORDER BY filename DESC LIMIT 20

   fisher

18 — 27.11.20 — 17:48

Чистка ConfigSave может помочь в простом случае.

Еще если рухнуло во время обновления конфигурации БД, может помочь удаление файлов .new

Где-то на просторах находил развернутую инструкцию по удалению всевозможных «хвостов» из Config, что может помочь в таких случаях, но сейчас нагуглить не получается. В основном только простые рецепты.

  

Garry1010

19 — 29.11.20 — 17:59

Ооо, чистка

DELETE FROM [dbo].[ConfigSave]

помогла!

Спасибо ВСЕМ!!!

Создаю кластер на 2 нодах с сетевым хранилищем для дисков.
сеть доступа 1G 192.168.0.0/24
Сеть для дисков 10G 172.10.10.0/24
Создан OU для кластера, сервера перенесены в OU. Создан вручную computer : EKAT-CL и отключен.
Пытаюсь создать от domain admin.
Проверка кластера проходит успешно (кроме обновления, там отличаются немного версии обнов)

При попытке создать выдает ошибку:

Начало настройки кластера EKAT-CL.
Произошла ошибка при создании кластера. Узлы будут очищены. Пожалуйста, подождите...
Произошла ошибка при создании кластера. Узлы будут очищены. Пожалуйста, подождите...
Произошла ошибка при очистке узлов кластера. Воспользуйтесь командой Clear-ClusterNode, чтобы очистить узлы вручную.
Произошла ошибка при очистке узлов кластера. Воспользуйтесь командой Clear-ClusterNode, чтобы очистить узлы вручную.
Произошла ошибка при создании кластера.
Возникла ошибка при создании кластера "EKAT-CL".

Параметр задан неверно
Для устранения неполадок при создании кластера запустите мастер проверки конфигурации на серверах, которые вы хотите включить в кластер.

Не могу понят в чем трабл.

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

.

Проблема 1

Служба кластеров при запуске обнаруживает сети, в которые входит узел, и для каждой сети определяет сетевые адаптеры. Одна из типичных неполадок связана с тем, что отказоустойчивая кластеризация Windows Server (WSFC) допускает использование для одной сети только одного сетевого адаптера. Все прочие адаптеры этой сети игнорируются.

Предположим, что администратор настроил узел с двумя сетевыми адаптерами для одной сети:

Card1
IP Address: 10.10.10.1
Subnet Mask: 255.0.0.0
Card2
IP Address: 10.10.10.2
Subnet Mask: 255.0.0.0

Сетевой драйвер кластера (Netft.sys) для каждой сети будет использовать только один сетевой адаптер (или группу). Поэтому при данной конфигурации сеть кластера Cluster Network 1 (10.10.10.0/16) будет задействовать только сетевой адаптер Card1, тогда как сетевой адаптер Card2 будет игнорироваться, то есть не будет применяться для связи между узлами. Поскольку работает только одна сеть, при выходе Card1 из строя или утрате сетевого соединения узел не сможет взаимодействовать с другими узлами. Это единственная точка отказа. Чтобы избежать подобной ситуации, кластер следует настраивать так, чтобы между узлами существовало, как минимум, два сетевых пути. В этом случае при отказе одного из сетевых адаптеров связь между узлами будет осуществляться через другой сетевой адаптер.

Проблема 2

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

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

Card1
IP Address: 192.168.0.1 (Cluster Network 1)
Subnet Mask: 255.255.255.0
Card2
IP Address: 10.10.10.1 (Cluster Network 2)
Subnet Mask: 255.0.0.0

Кроме того, администратор поменял IP-адреса узла Node2 (192.168.0.2 и 10.10.10.2). При этом на узле Node1 в кластере он добавил группу файлового сервера, назначив ей IP-адрес 192.168.0.15.

Затем администратор протестировал кластер, чтобы убедиться в успешном переходе группы файлового сервера на узел Node2 при отработке отказа. Однако IP-адрес группы файлового сервера не виден в сети, то есть группа находится в автономном состоянии. В журнале событий системы регистрируется событие 1069, описание которого указывает на отказ ресурса с этим IP-адресом.

Причина отказа становится очевидной, если воспользоваться командой PowerShell Get-ClusterLog для вывода журнала кластера. Для этого достаточно ввести следующий набор символов:

Get-ClusterLog

Команда инициирует создание журнала кластера на каждом узле. Для построения журнала кластера только на одном узле можно добавить параметр -Node и указать имя узла. Можно также добавить параметр -TimeSpan для создания журнала только за последние x минут. Например, приведенная ниже команда предписывает построить журнал кластера на узле Node2 за последние 15 минут:

Get-ClusterLog –Node Node2 –TimeSpan 15

В результатах, представленных на экране 1, указано состояние «status 5035.».

Информация о состоянии 5035 в файле журнала кластера
Экран 1. Информация о состоянии 5035 в файле журнала кластера

Это сообщение об ошибке указывает на неработоспособное состояние сети кластера. Если администратор перейдет в диспетчер отказоустойчивости кластеров, то в разделе «Сети» он увидит, что сеть 192.168.0.0/24 содержит только один сетевой адаптер для узла Node1. Однако имеется новая сеть 192.0.0.0/8, обслуживаемая сетевым адаптером узла Node2. Администратор, поменяв IP-адрес сетевого адаптера на узле Node2, не поменял маску подсети. Таким образом, ошибка 5035 возникла из-за неверной настройки сетевого адаптера.

Создавая ресурс с IP-адресом, можно указать сеть, которая будет использоваться для него. Если эта сеть не будет существовать на узле, куда данный ресурс перейдет при отработке отказа, то WSFC не поменяет сеть, используемую ресурсом. В данном примере, при том IP-адресе, который указал администратор, и маске подсети, применяемой этим IP-адресом, группа файлового сервера сможет работать только по сети Cluster Network 1 (192.168.0.0/24).

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

Создание многосайтового кластера
Экран 2. Создание многосайтового кластера

Мастер создания ресурсов, создавая IP-адреса и назначая имя сети, автоматически присваивает параметру зависимости этого имени сети значение «или». Это означает, что если один из IP-адресов в сети, имя также видно в сети. Создавая группы или ресурсы перед добавлением узлов из других сетей, необходимо вручную создавать эти вторичные IP-адреса и добавлять зависимость «или».

Проблема 3

Для формирования кластера необязательно быть администратором домена, но создание объектов в Active Directory (AD) требует наличия соответствующих прав. Как минимум, необходимо обладать правами на просмотр и создание объектов (Read and Create) в том подразделении (OU), где создается данный объект имени кластера (CNO). CNO – это объект-компьютер, связанный с ресурсом-кластером «Имя кластера». При создании кластера служба WSFC использует учетную запись, с которой вы регистрировались в системе, чтобы создать объект CNO в том же OU, которому принадлежат узлы. Если вы не обладаете достаточными правами в отношении данного OU, кластер не будет создан, и система выдаст ошибку, как показано на экране 3.

Ошибка процесса создания кластера
Экран 3. Ошибка процесса создания кластера

В статье «Диагностика проблем отказоустойчивых кластеров Windows Server 2012» (№ 10 за 2013 г.) я рассказывал об использовании мастера проверки конфигурации в диспетчере отказоустойчивости кластеров для выявления причин возникающих проблем. Мастер позволяет выполнять различные тесты, включая проверку настроек Active Directory. В ответ на попытку запуска этого теста без достаточных прав в отношении данного OU будет выдана ошибка, как показано на экране 4. Соответствующая настройка прав позволит вам создать кластер.

Ошибка проверки настроек Active Directory
Экран 4. Ошибка проверки настроек Active Directory

Все другие ресурсы с сетевыми именами в кластере ассоциированы с объектами виртуальных компьютеров (VCO), создаваемыми в том же OU, что и CNO. Следовательно, при назначении ролей в кластере необходимо указать CNO с соответствующими правами (просмотр и создание) в отношении OU, поскольку CNO формирует все VCO в кластере. В противном случае новая роль будет находиться в состоянии сбоя. Тогда в журнале появится событие 1194 (см. экран 5).

Событие 1194 в журнале событий системы
Экран 5. Событие 1194 в журнале событий системы

Есть и другие установки локального компьютера, способные вызвать ошибки (включая ошибки отказа в доступе) при создании VCO в AD.

1. В составе локальной группы «Пользователи» больше нет группы «Прошедшие проверку пользователи». Обычно она удаляется объектами групповой политики (GPO) или шаблонами безопасности.

2. В локальной политике безопасности разрешение Access this computer from the network («Доступ к этому компьютеру по сети») или Add workstations to the domain («Добавление рабочих станций к домену») больше не включает группу «Прошедшие проверку пользователи». Обычно она удаляется объектами групповой политики (GPO) или шаблонами безопасности.

3. Включены следующие права доступа:

  • сетевой доступ (не разрешать перечисление учетных записей SAM анонимными пользователями);
  • сетевой доступ (не разрешать перечисление учетных записей SAM и общих ресурсов анонимными пользователями).

4. Ресурс имени кластера в состоянии сбоя.

Проблема 4

CNO и VCO – учетные записи компьютера и, подобно учетным записям пользователей, они имеют пароли, генерируемые AD случайным образом. По умолчанию политика домена предусматривает сброс пароля учетной записи компьютера каждые 60 дней.

СNO используется для таких операций, как добавление новых узлов к кластеру, создание новых объектов в домене и выполнение динамической миграции виртуальных машин с узла на узел. Для выполнения этих операций пароль CNO в домене должен быть актуальным. Для верности служба кластера делает попытку сброса паролей этих объектов по истечении половины срока (через 30 дней). Если пароль не сброшен на 60-дневной отметке, имя кластера не видно в сети.

Для сброса пароля необходимо выполнить восстановление в диспетчере отказоустойчивости кластеров. Как показано на экране 6, щелкните правой кнопкой имя проблемного ресурса и выберите «Дополнительные действия» и «Восстановить».

Сброс пароля вручную в диспетчере отказоустойчивости кластеров
Экран 6. Сброс пароля вручную в диспетчере отказоустойчивости кластеров

При обращении к AD для сброса пароля диспетчер отказоустойчивости кластеров задействует учетную запись пользователя, под которой вы зарегистрировались в системе, поэтому вашей учетной записи должно быть предоставлено право на изменение пароля CNO; в противном случае восстановление не будет выполнено. Необходимо также убедиться, что включено разрешение на сброс пароля CNO и VCO, чтобы служба WSFC могла выполнять сброс при необходимости.

Проблема 5

Чтобы узел был осведомлен о том, какие узлы являются активными участниками кластера (то есть о текущем членстве), применяется ряд периодических контрольных сигналов, передаваемых между узлами по сети. Эти пакеты сигналов представляют собой UDP-датаграммы, следующие через порт 3343.

Каждый пакет включает регистрационный номер, по которому отслеживается факт приема пакета. Это работает следующим образом: узел Node1, отправляющий регистрационный номер 1111, ожидает ответного пакета, включающего 1111. Эти действия совершаются между всеми узлами каждую секунду. Если узел Node1 не получает ответного пакета, он отправляет следующий по порядку регистрационный номер (1112), и т.д.

По умолчанию, если узел не получает пять контрольных сигналов в течение пяти секунд, WSFC устанавливает факт отказа узла. Активный узел в кластере отправляет пакет на узел, где установлен отказ, чтобы завершить работу службы кластера, и регистрирует событие 1135 в журнале событий системы (см. экран 7).

Событие 1135 в журнале событий системы
Экран 7. Событие 1135 в журнале событий системы

Такое событие может быть вызвано несколькими причинами, многие из которых связаны с блокировкой связи через порт 3343:

1. Отказ сетевого оборудования.

2. Устаревший драйвер или устаревшая прошивка сетевого адаптера.

3. Сетевая задержка.

4. Протокол IPv6 разрешен на серверах, но параметры брандмауэра Windows выключают следующие разрешения для входящего и исходящего трафика:

  • основы сетей – объявление поиска соседей;
  • основы сетей – запрос поиска соседей.

5. Настройка коммутаторов, брандмауэров или маршрутизаторов не допускает прохождения трафика данных UDP-датаграмм.

6. Проблемы производительности (зависания, задержки и прочее).

7. Неправильно настроенные параметры буфера приема у драйвера сетевого адаптера.

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

Для добавления счетчика отброшенных принятых пакетов в окне системного монитора щелкните правой кнопкой на дисплее и выберите «Добавить счетчики». В открывшемся окне добавления счетчиков укажите нужный компьютер, выполните прокрутку и выберите счетчик «Отброшено принятых пакетов». В выпадающем списке «Экземпляры выбранного объекта» выберите нужный сетевой адаптер и нажмите «Добавить» (см. экран 8).

Добавление счетчика отброшенных принятых пакетов в системный монитор
Экран 8. Добавление счетчика отброшенных принятых пакетов в системный монитор

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

В отказоустойчивом кластере Windows Server 2012 R2 можно воспользоваться мастером проверки конфигурации для выполнения проверки сетевого взаимодействия. Этот тест позволяет проверить возможность информационного обмена между узлами через порт 3343. Если есть проблемы связи, то будет выдана соответствующая ошибка с указанием возможной причины.

Проблема 6

Иногда диспетчер отказоустойчивости кластеров не открывается, выдавая сообщение об ошибке (см. экран 9). В процессе открытия диспетчер отказоустойчивости кластеров устанавливает WMI-соединение с каждым узлом кластера. Сообщение об ошибке, приведенное на экране 9, указывает на то, что один из узлов имеет недопустимое пространство имен, то есть с узла был удален экземпляр Cluster WMI (Cluswmi.mof). Остается выяснить, на котором из узлов он удален, поскольку в сообщении об ошибке эта информация отсутствует.

Сообщение о недопустимом пространстве имен
Экран 9. Сообщение о недопустимом пространстве имен

В листинге приведен сценарий Windows PowerShell, позволяющий выявить узел, утративший экземпляр Cluster WMI.

Установив проблемный узел, можно ввести команду

Set-Location C:WindowsSystem32Wbem
Mofcomp.exe Cluswmi.mof

Наиболее распространенной причиной утраты Cluswmi.mof узлом является устаревший способ решения проблем WMI. Для устранения неполадок WMI администраторы обычно используют команду Mofcomp.exe *.mof, позволяющую скомпилировать все файлы Managed Object Format (MOF) в репозиторий WMI. Однако дело в том, что существует довольно много файлов удаления для различных ролей и компонентов Windows, включая Cluster WMI. Поэтому файл Cluswmi.mof, устанавливаемый с помощью этой команды, впоследствии удаляется. Правильный способ восстановления репозитория WMI – с использованием команды Winmgmt.exe.

Ошибку легче предупредить

Как известно, предупредить ошибку легче, чем исправлять ее последствия. Поэтому в заключение повторю простое правило: регулярно актуализируйте состояние своих систем, применяя все обновления и исправления, касающиеся безопасности. Команда разработчиков отказоустойчивой кластеризации в Microsoft опубликовала материалы с перечнями исправлений, которые рекомендуется применить на всех кластерах. Каждой версии Windows посвящена отдельная публикация:

  • «Рекомендуемые исправления и обновления для отказоустойчивых кластеров на базе Windows Server 2012 R2» (support.microsoft.com/kb/2920151/EN-US);
  • «Рекомендуемые исправления и обновления для отказоустойчивых кластеров на базе Windows Server 2012» (support.microsoft.com/kb/2784261/EN-US);
  • «Рекомендуемые исправления и обновления для отказоустойчивых кластеров на базе Windows Server 2008 R2» (support.microsoft.com/kb/980054/EN-US).

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

Листинг. Сценарий PowerShell для определения узлов с отсутствующим экземпляром Cluster WMI

$NodeNames = Get-ClusterNode
ForEach ($ClusterName in $NodeNames)
{
Write-Host -NoNewline «Testing $ClusterName»
Try
{
$result = (Get-WmiObject -Class «MSCluster_CLUSTER» `
-namespace «rootMSCluster» `
-authentication PacketPrivacy `
-computername $ClusterName -erroraction stop).__SERVER
Write-host «: Successfully queried cluster node»
}
Catch
{
Write-host -NoNewline «: Failed to query cluster node»
Write-host -ForegroundColor Red -BackgroundColor Black `
$_.Exception.Message
}
}

При добавлении сервера ‘EXCHANGE2010’ в группу DAG выдает ошибку:

Сводка: всего элементов: 1. Успешно: 0, с ошибками: 1.
Прошло времени: 00:00:08

EXCHANGE2010
Ошибка

Ошибка:
Сбой серверной административной операции группы обеспечения доступности баз данных. Ошибка: Сбой операции. Ошибки CreateCluster могут возникать в результате неправильной настройки статических адресов. Ошибка: Произошла ошибка при выполнении операции кластера.
Ошибка: Сбой API кластера ‘Ошибка CreateCluster(): 0x13c1. Ошибка: IP-адрес кластера уже используется’. [Сервер: EXCHANGE2010.domain.com]

Сбой операции Active Manager. Ошибка Произошла ошибка при выполнении операции кластера. Ошибка: Сбой API кластера ‘Ошибка CreateCluster(): 0x13c1. Ошибка: IP-адрес кластера уже используется’..

IP-адрес кластера уже используется
Щелкните здесь для справки…
http://technet.microsoft.com/ru-RU/library/ms.exch.err.default(EXCHG.140).aspx?v=14.2.283.3&t=exchgf1&e=ms.exch.err.ExC9C315

Предупреждение:
У сервера ‘EXCHANGE2010’ имеется несколько сетевых адаптеров, на которых настроены шлюзы по умолчанию. Использовать такую конфигурацию не рекомендуется. Определять шлюз по умолчанию рекомендуется только на одном сетевом интерфейсе. Дополнительные сети должны
использовать для настройки потока трафика статические маршруты. Дополнительные сведения см. в разделе файла справки «Планирование высокого уровня доступности и устойчивости сайта».

Предупреждение:
Операция завершилась неудачей из-за обнаруженной ошибки. Дополнительные сведения см. в файле журнала «C:ExchangeSetupLogsDagTasksdagtask_2012-05-16_09-57-28.686_add-databaseavailabiltygroupserver.log».

Попытка выполнения команды командной консоли Exchange:
Add-DatabaseAvailabilityGroupServer -MailboxServer ‘EXCHANGE2010’ -Identity ‘DAGServers’

Прошло времени: 00:00:08

 

Файл “C:ExchangeSetupLogsDagTasksdagtask_2012-05-16_09-57-28.686_add-databaseavailabiltygroupserver.log”
add-databaseavailabiltygroupserver started on machine EXCHANGE2010.
[2012-05-16T09:57:28] add-dagserver started
[2012-05-16T09:57:28] commandline:         $scriptCmd = {& $wrappedCmd @PSBoundParameters }
[2012-05-16T09:57:28] Option ‘Identity’ = ‘DAGServers’.
[2012-05-16T09:57:28] Option ‘MailboxServer’ = ‘EXCHANGE2010’.
[2012-05-16T09:57:28] Option ‘DatabaseAvailabilityGroupIpAddresses’ = ».
[2012-05-16T09:57:28] Option ‘WhatIf’ = ».
[2012-05-16T09:57:28] Process: w3wp w3wp.exe:1172.
[2012-05-16T09:57:28] User context = ‘NT AUTHORITYсистема’.
[2012-05-16T09:57:28]   Member of group ‘Все’.
[2012-05-16T09:57:28]   Member of group ‘BUILTINПред-Windows 2000 доступ’.
[2012-05-16T09:57:28]   Member of group ‘BUILTINПользователи’.
[2012-05-16T09:57:28]   Member of group ‘BUILTINДоступ DCOM службы сертификации’.
[2012-05-16T09:57:28]   Member of group ‘NT AUTHORITYСЛУЖБА’.
[2012-05-16T09:57:28]   Member of group ‘КОНСОЛЬНЫЙ ВХОД’.
[2012-05-16T09:57:28]   Member of group ‘NT AUTHORITYПрошедшие проверку’.
[2012-05-16T09:57:28]   Member of group ‘NT AUTHORITYДанная организация’.
[2012-05-16T09:57:28]   Member of group ‘BUILTINIIS_IUSRS’.
[2012-05-16T09:57:28]   Member of group ‘ЛОКАЛЬНЫЕ’.
[2012-05-16T09:57:28]   Member of group ‘IIS APPPOOLMSExchangePowerShellAppPool’.
[2012-05-16T09:57:28]   Member of group ‘BUILTINАдминистраторы’.
[2012-05-16T09:57:28] Updated Progress ‘Проверка параметров.’ 2%.
[2012-05-16T09:57:28] Выполняется
[2012-05-16T09:57:28] Mailbox server: value passed in = EXCHANGE2010, mailboxServer.Name = EXCHANGE2010, mailboxServer.Fqdn = EXCHANGE2010.domain.com
[2012-05-16T09:57:28] LogClussvcState: clussvc is Stopped on EXCHANGE2010.domain.com. Exception (if any) = none
[2012-05-16T09:57:28] The IP addresses for the DAG are (blank means DHCP): 192.168.0.105
[2012-05-16T09:57:28] Looking up IP addresses for DAGServers.
[2012-05-16T09:57:28]   DAGServers = [ 192.168.0.105 ].
[2012-05-16T09:57:28] Looking up IP addresses for EXCHANGE2010.
[2012-05-16T09:57:28]   EXCHANGE2010 = [ fe80::9589:15c8:ae4d:b88c%13, fe80::f800:456b:5aca:8eda%11, 2002:c22c:a6f2::c22c:a6f2, 2002:c22c:a6f3::c22c:a6f3, 192.168.0.1, 10.10.10.1, 194.44.3.2, 194.44.3.3 ].
[2012-05-16T09:57:28] Looking up IP addresses for EXCHANGE2010.domain.com.
[2012-05-16T09:57:28]   EXCHANGE2010.domain.com = [ fe80::9589:15c8:ae4d:b88c%13, fe80::f800:456b:5aca:8eda%11, 2002:c22c:a6f2::c22c:a6f2, 2002:c22c:a6f3::c22c:a6f3, 192.168.0.1, 10.10.10.1, 194.44.3.2, 194.44.3.3 ].
[2012-05-16T09:57:28] DAG DAGServers has 0 servers:
[2012-05-16T09:57:28] Updated Progress ‘Идет проверка, входит ли сервер почтовых ящиков ‘EXCHANGE2010′ в группу доступности баз данных.’ 4%.
[2012-05-16T09:57:28] Выполняется
[2012-05-16T09:57:28] GetRemoteCluster() for the mailbox server failed with exception = Сбой операции Active Manager. Ошибка Произошла ошибка при выполнении операции кластера. Ошибка: Сбой API кластера ‘Ошибка OpenCluster(EXCHANGE2010.domain.com): 0x6d9. Ошибка:
В системе отображения конечных точек не осталось доступных конечных точек’… This is OK.
[2012-05-16T09:57:28] Ignoring previous error, as it is acceptable if the cluster does not exist yet.
[2012-05-16T09:57:28] DumpClusterTopology: Opening remote cluster DAGServers.
[2012-05-16T09:57:28] DumpClusterTopology: Failed opening with Microsoft.Exchange.Cluster.Replay.AmGetFqdnFailedNotFoundException: Сбой операции Active Manager: временная ошибка. Повторите операцию. Ошибка Не удалось найти полное доменное имя для узла ‘DAGServers’.
   в Microsoft.Exchange.Cluster.ActiveManagerServer.AmServerNameCache.<>c__DisplayClass1.<ResolveFqdn>b__0(Object , EventArgs )
   в Microsoft.Exchange.Cluster.ActiveManagerServer.AmHelper.RunADOperationEx(EventHandler ev)
   в Microsoft.Exchange.Cluster.ActiveManagerServer.AmServerNameCache.ResolveFqdn(String shortNodeName)
   в Microsoft.Exchange.Cluster.ActiveManagerServer.AmServerNameCache.GetFqdn(String shortNodeName)
   в Microsoft.Exchange.Cluster.ActiveManagerServer.AmServerName..ctor(String serverName)
   в Microsoft.Exchange.Management.SystemConfigurationTasks.DumpClusterTopology..ctor(String nameCluster, ITaskOutputHelper output)
[2012-05-16T09:57:28] Dumping the cluster by connecting to: DAGServers.
[2012-05-16T09:57:28] DumpClusterTopology: Not dumping, since the cluster could not be contacted.
[2012-05-16T09:57:28] The new server (EXCHANGE2010) is not a member of a cluster, nor are the other servers (if there are any other servers).
[2012-05-16T09:57:28] The computer account DAGServers does not exist.
[2012-05-16T09:57:28] According to GetNodeClusterState(), the server EXCHANGE2010 is NotConfigured.
[2012-05-16T09:57:28] InternalValidate() done.
[2012-05-16T09:57:28] Updated Progress ‘Добавление сервера ‘EXCHANGE2010’ в группу доступности баз данных ‘DAGServers’.’ 6%.
[2012-05-16T09:57:28] Выполняется
[2012-05-16T09:57:28] Connecting to server ‘EXCHANGE2010.domain.com’ via WMI…
[2012-05-16T09:57:28] Fetching the network adapters and including the ones without default gateways.
[2012-05-16T09:57:28] EXCHANGE2010.domain.com has an address: 10.10.10.1/24 default gateway(s)=0.0.0.0 [valid]
[2012-05-16T09:57:28] IP address derived that’s suitable for clustering DHCP/IPv6: 10.10.10.0/24.
[2012-05-16T09:57:28] EXCHANGE2010.domain.com has an address: 194.44.3.3/29 default gateway(s)=194.44.3.1 [valid]
[2012-05-16T09:57:28] IP address derived that’s suitable for clustering DHCP/IPv6: 194.44.3.0/29.
[2012-05-16T09:57:28] EXCHANGE2010.domain.com has an address: 194.44.3.2/29 default gateway(s)=194.44.3.1 [valid]
[2012-05-16T09:57:28] IP address derived that’s suitable for clustering DHCP/IPv6: 194.44.3.0/29.
[2012-05-16T09:57:28] EXCHANGE2010.domain.com has an address: fe80::f800:456b:5aca:8eda/64 default gateway(s)=194.44.3.1 [invalid]
[2012-05-16T09:57:28] EXCHANGE2010.domain.com has an address: 192.168.0.1/24 default gateway(s)=fe80::ccce:a1bf:beb6:20f5 [valid]
[2012-05-16T09:57:28] IP address derived that’s suitable for clustering DHCP/IPv6: 192.168.0.0/24.
[2012-05-16T09:57:28] EXCHANGE2010.domain.com has an address: fe80::9589:15c8:ae4d:b88c/64 default gateway(s)=fe80::ccce:a1bf:beb6:20f5 [invalid]
[2012-05-16T09:57:28] У сервера ‘EXCHANGE2010’ имеется несколько сетевых адаптеров, на которых настроены шлюзы по умолчанию. Использовать такую конфигурацию не рекомендуется. Определять шлюз по умолчанию рекомендуется только на одном сетевом интерфейсе. Дополнительные
сети должны использовать для настройки потока трафика статические маршруты. Дополнительные сведения см. в разделе файла справки «Планирование высокого уровня доступности и устойчивости сайта».
[2012-05-16T09:57:28] The address 192.168.0.105 falls under the network (192.168.0.0/24).
[2012-05-16T09:57:28] Updated Progress ‘Формируется кластер с именем ‘DAGServers’ на сервере ‘EXCHANGE2010′.’ 8%.
[2012-05-16T09:57:28] Выполняется
[2012-05-16T09:57:28] Формируется кластер с именем ‘DAGServers’ на сервере ‘EXCHANGE2010’. Адрес кластера: [192.168.0.105]; длина префикса сети кластеров: [24].
[2012-05-16T09:57:37] Следующая запись журнала поступила от другого процесса, запущенного на компьютере ‘EXCHANGE2010’. BEGIN
[2012-05-16T09:57:37] [2012-05-16T09:57:28] Updated Progress ‘Формируется кластер с именем ‘DAGServers’ на сервере ‘EXCHANGE2010′.’ 2%.
[2012-05-16T09:57:28] Выполняется
[2012-05-16T09:57:28] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseInitialize, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 5, szObjectName = DAGServers, dwStatus = 0x0 )
[2012-05-16T09:57:28] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseInitialize, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 5, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:28] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseValidateNodeState, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 10, szObjectName = EXCHANGE2010.domain.com, dwStatus
= 0x0 )
[2012-05-16T09:57:28] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseValidateNodeState, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 10, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseQueryClusterNameAccount, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 15, szObjectName = DAGServers, dwStatus = 0x0
)
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseQueryClusterNameAccount, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 15, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseCreateClusterAccount, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 21, szObjectName = DAGServers, dwStatus = 0x0
)
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseCreateClusterAccount, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 21, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseConfigureClusterAccount, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 26, szObjectName = DAGServers, dwStatus = 0x0
)
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseConfigureClusterAccount, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 26, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseValidateNetft, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 31, szObjectName = EXCHANGE2010.domain.com, dwStatus
= 0x0 )
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseValidateNetft, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 31, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseValidateClusDisk, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 36, szObjectName = EXCHANGE2010.domain.com, dwStatus
= 0x0 )
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseValidateClusDisk, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 36, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:29] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseConfigureClusSvc, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 42, szObjectName = EXCHANGE2010.domain.com, dwStatus
= 0x0 )
[2012-05-16T09:57:30] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseConfigureClusSvc, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 42, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:30] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseStartingClusSvc, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 47, szObjectName = EXCHANGE2010.domain.com, dwStatus
= 0x0 )
[2012-05-16T09:57:30] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseStartingClusSvc, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 47, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:30] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseFormingCluster, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 52, szObjectName = DAGServers, dwStatus = 0x0 )
[2012-05-16T09:57:32] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseFormingCluster, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 52, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:32] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseAddClusterProperties, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 57, szObjectName = DAGServers, dwStatus = 0x0
)
[2012-05-16T09:57:32] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseAddClusterProperties, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 57, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:32] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseCreateResourceTypes, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 63, szObjectName = DAGServers, dwStatus = 0x0 )
[2012-05-16T09:57:33] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseCreateResourceTypes, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 63, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:33] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseCreateGroups, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 68, szObjectName = Кластерная группа, dwStatus = 0x0 )
[2012-05-16T09:57:33] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseCreateGroups, ePhaseType = ClusterSetupPhaseContinue, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 68, szObjectName = Доступное хранилище, dwStatus =
0x0 )
[2012-05-16T09:57:34] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseCreateGroups, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 68, szObjectName = , dwStatus = 0x0 )
[2012-05-16T09:57:34] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseCreateIPAddressResources, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 73, szObjectName = IP-адрес кластера, dwStatus
= 0x0 )
[2012-05-16T09:57:34] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseCreateIPAddressResources, ePhaseType = ClusterSetupPhaseContinue, ePhaseSeverity = ClusterSetupPhaseWarning, dwPercentComplete = 73, szObjectName = IP-адрес кластера, dwStatus
= 0x13c1 )
[2012-05-16T09:57:34] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseCreateIPAddressResources, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseFatal, dwPercentComplete = 73, szObjectName = IP-адрес кластера, dwStatus = 0x13c1
)
[2012-05-16T09:57:34] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseFailureCleanup, ePhaseType = ClusterSetupPhaseStart, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 73, szObjectName = Кластерная группа, dwStatus = 0x0
)
[2012-05-16T09:57:34] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseFailureCleanup, ePhaseType = ClusterSetupPhaseContinue, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 73, szObjectName = EXCHANGE2010.domain.com, dwStatus
= 0x0 )
[2012-05-16T09:57:36] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseFailureCleanup, ePhaseType = ClusterSetupPhaseContinue, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 73, szObjectName = DAGServers, dwStatus = 0x0 )

[2012-05-16T09:57:36] ClusterSetupProgressCallback( eSetupPhase = ClusterSetupPhaseFailureCleanup, ePhaseType = ClusterSetupPhaseEnd, ePhaseSeverity = ClusterSetupPhaseInformational, dwPercentComplete = 73, szObjectName = , dwStatus = 0x0 )

[2012-05-16T09:57:37] Операция завершилась неудачей из-за обнаруженной ошибки. Дополнительные сведения см. в файле журнала «C:ExchangeSetupLogsDagTasksdagtask_2012-05-16_09-57-28.686_add-databaseavailabiltygroupserver.log».
[2012-05-16T09:57:37] WriteError! Exception = Microsoft.Exchange.Cluster.Replay.DagTaskOperationFailedException: Сбой серверной административной операции группы обеспечения доступности баз данных. Ошибка: Сбой операции. Ошибки CreateCluster могут возникать
в результате неправильной настройки статических адресов. Ошибка: Произошла ошибка при выполнении операции кластера. Ошибка: Сбой API кластера ‘Ошибка CreateCluster(): 0x13c1. Ошибка: IP-адрес кластера уже используется’. —> Microsoft.Exchange.Cluster.Replay.AmClusterApiException:
Сбой операции Active Manager. Ошибка Произошла ошибка при выполнении операции кластера. Ошибка: Сбой API кластера ‘Ошибка CreateCluster(): 0x13c1. Ошибка: IP-адрес кластера уже используется’.. —> System.ComponentModel.Win32Exception: IP-адрес кластера
уже используется
   — Конец трассировки внутреннего стека исключений —
   в Microsoft.Exchange.Cluster.ClusApi.AmCluster.CreateExchangeCluster(String clusterName, AmServerName firstNodeName, String[] ipAddress, UInt32[] ipPrefixLength, IClusterSetupProgress setupProgress, IntPtr context, Exception& failureException,
Boolean throwExceptionOnFailure)
   в Microsoft.Exchange.Cluster.Replay.DagHelper.CreateDagCluster(String clusterName, AmServerName firstNodeName, String[] ipAddresses, UInt32[] netmasks, String& verboseLog)
   — End of inner exception stack trace (Microsoft.Exchange.Cluster.Replay.AmClusterApiException) —
   в Microsoft.Exchange.Cluster.Replay.DagHelper.ThrowDagTaskOperationWrapper(Exception exception)
   в Microsoft.Exchange.Cluster.Replay.DagHelper.CreateDagCluster(String clusterName, AmServerName firstNodeName, String[] ipAddresses, UInt32[] netmasks, String& verboseLog)
   в Microsoft.Exchange.Cluster.ReplayService.ReplayRpcServer.<>c__DisplayClass2e.<RpcsCreateCluster>b__2d()
   в Microsoft.Exchange.Data.Storage.Cluster.HaRpcExceptionWrapperBase`2.RunRpcServerOperation(String databaseName, RpcServerOperation rpcOperation)
   — End of stack trace on server (EXCHANGE2010.domain.com) —
   в Microsoft.Exchange.Data.Storage.Cluster.HaRpcExceptionWrapperBase`2.ClientRethrowIfFailed(String databaseName, String serverName, RpcErrorExceptionInfo errorInfo)
   в Microsoft.Exchange.Cluster.Replay.ReplayRpcClientWrapper.RunRpcOperationDbName(AmServerName serverName, String databaseName, Int32 timeoutMs, IHaRpcExceptionWrapper rpcExceptionWrapperInstance, InternalRpcOperation rpcOperation)
   в Microsoft.Exchange.Cluster.Replay.ReplayRpcClientWrapper.RunRpcOperation(AmServerName serverName, Nullable`1 dbGuid, Int32 timeoutMs, IHaRpcExceptionWrapper rpcExceptionWrapperInstance, InternalRpcOperation rpcOperation)
   в Microsoft.Exchange.Cluster.Replay.ReplayRpcClientWrapper.RunCreateCluster(AmServerName rpcServerName, String clusterName, AmServerName firstNode, String[] ipaddrs, UInt32[] netmasks, String& verboseLog)
   в Microsoft.Exchange.Management.SystemConfigurationTasks.AddDatabaseAvailabilityGroupServer.FormCluster()
[2012-05-16T09:57:37] Updated Progress ‘Готово!’ 100%.
[2012-05-16T09:57:37] ЗАВЕРШЕНО
add-databaseavailabiltygroupserver explicitly called CloseTempLogFile().

Помогите устранить вопрос.


Microsoft

0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

А вот еще интересные материалы:

  • Яшка сломя голову остановился исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного исправьте ошибки
  • Ясность цели позволяет целеустремленно добиваться намеченного где ошибка
  • Ошибка создания персонажа вов
  • Ошибка создания файла носитель защищен от записи