Убедитесь что для объекта имени кластера cno установлены разрешения на доступ к безопасной зоне dns
Иногда при установке служб Microsoft Active Directory Domain Services (AD DS) в среде Windows Server 2008 или Server 2008 R2 возникают две проблемы. Одна из них относится к процессу установки; другая связана с рекомендациями компании Microsoft по запуску контроллеров домена (DC) на виртуальных машинах. Эти проблемы известны опытным администраторам. Но начинающим специалистам, которым необходимо заменить операционную систему контроллера домена с Windows Server 2003 на Server 2008 R2, будет очень полезна эта статья, в которой я планирую рассмотреть все возможные трудности и пути их преодоления
Иногда при установке служб Microsoft Active Directory Domain Services (AD DS) в среде Windows Server 2008 или Server 2008 R2 возникают две проблемы. Одна из них относится к процессу установки; другая связана с рекомендациями компании Microsoft по запуску контроллеров домена (DC) на виртуальных машинах.
Эти проблемы известны опытным администраторам. Но начинающим специалистам, которым необходимо заменить операционную систему контроллера домена с Windows Server 2003 на Server 2008 R2, будет очень полезна эта статья, в которой я планирую рассмотреть все возможные трудности и пути их преодоления.
Что нужно знать перед началом работы
Предполагаемое время для завершения: 1 минута
Необходимо использовать учетную запись, имеющую разрешения на создание объектов компьютеров в Active Directory.
После выполнения следующих шагов дождитесь окончания репликации Active Directory. После репликации объекта можно добавить первый сервер в группу доступности баз данных.
Возникли проблемы? Попросите помощи на форумах Exchange. Перейти на форумы можно по следующим ссылкам: Exchange Server, Exchange Online или Exchange Online Protection.
Откройте пункт "Пользователи и компьютеры Active Directory".
Разверните узел леса.
Щелкните правой кнопкой мыши подразделение, в котором необходимо создать новую учетную запись, выберите команду Создать, а затем щелкните Компьютер.
Шаг 3. Предоставление разрешений CNO подразделению или подготовка VCO для кластерных ролей
Когда вы создаете кластерную роль с точкой доступа клиента, кластер создает VCO в том же подразделении, что и CNO. Чтобы это происходило автоматически, CNO должен иметь разрешения на создание объектов-компьютеров в подразделении.
Если вы подготовили CNO в AD DS, для создания VCO можно сделать следующее.
- Вариант 1: предоставить разрешения CNO подразделению. Если вы воспользуетесь этим вариантом, кластер сможет автоматически создавать VCO в AD DS. Таким образом, администратор отказоустойчивого кластера сможет создавать кластерные роли, не отправляя вам запрос на подготовку VCO в AD DS.
Необходимым минимумом для выполнения шагов этого варианта является членство в группе Администраторы домена или эквивалентной группе.
- Вариант 2. Подготовка виртуальной машины для кластеризованной роли. Используйте этот вариант, если есть необходимость в подготовке учетных записей для кластерных ролей из-за требований в вашей организации. Например, если вы хотите контролировать использование имен или создание кластерных ролей.
Необходимым минимумом для выполнения шагов этого варианта является членство в группе Операторы учета.
Предварительная подготовка виртуальной машины для кластеризованной роли
Теперь администратор отказоустойчивого кластера может создать кластерную роль с точкой доступа клиента, которая соответствует подготовленному имени VCO, и подключить ресурсы.
В средах, в которых создание учетной записи компьютера ограничено или когда учетные записи компьютеров создаются в контейнере, помимо контейнера компьютеров по умолчанию, можно предварительно этапе объекта кластерного имени (CNO), а затем предоставления CNO, назначив ему разрешения.
Пользователь создает и отключает учетную запись компьютера для объекта CNO, а затем выполняет одно из указанных ниже действий.
Назначить разрешения на полный доступ к учетной записи компьютера для учетной записи компьютера, являющегося первым сервером почтовых ящиков, добавляемым в группу обеспечения доступности баз данных.
-Or-
Назначить полный доступ учетной записи компьютера универсальной группе безопасности доверенной подсистемы Exchange.
Шаг 1. Подготовка CNO в AD DS
Перед началом работы убедитесь, что знаете следующее:
- Имя, которое требуется назначить кластеру
- Имя учетной записи пользователя или группы, которой требуется предоставить права на создание кластера.
Мы рекомендуем создать подразделение для кластерных объектов. Если подразделение, которое вы хотите использовать, уже существует, для завершения этого шага требуется членство в группе Операторы учета. Если подразделение для кластерных объектов необходимо создать, для завершения этого шага требуется членство в группе Администраторы домена или аналогичной группе.
Если вы создали CNO в контейнере компьютеров по умолчанию, а не в подразделении, вам не нужно выполнять шаг 3 этого раздела. В этом сценарии администратор кластера может создать до 10 VCO без какой-либо дополнительной настройки.
Предоставление разрешений CNO подразделению
На странице "Пользователи и компьютеры Active Directory" в меню Вид убедитесь, что выбран пункт Дополнительные параметры.
Щелкните правой кнопкой мыши подразделение, в котором вы создали CNO на шаге 1. Подготовка CNO в AD DS и выберите пункт "Свойства".
На вкладке Безопасность нажмите кнопку Дополнительно.
В диалоговом окне "Расширенная безопасность Параметры" нажмите кнопку "Добавить".
Рядом с участником выберите "Выбрать участника".
В диалоговом окне "Выбор пользователя, компьютера, учетной записи службы или групп " выберите "Типы объектов", установите флажок "Компьютеры " и нажмите кнопку "ОК".
В диалоговом окне Запись разрешения убедитесь, что для списка Тип установлено значение Разрешить, а для списка Применяется к — значение Этот объект и все дочерние объекты.
В разделе Разрешения установите флажок Создание объектов-компьютеров.
Рис. 3. Предоставление CNO разрешения на создание объектов-компьютеров
Нажимайте кнопку "ОК", пока не вернеесь к оснастке Пользователи и компьютеры Active Directory.
Теперь администратор отказоустойчивого кластера может создать кластерные роли с точкой доступа клиента и подключить ресурсы.
Особенности Adprep
Когда в Windows Server 2003 впервые появилось требование выполнения команды adprep/forestprep, компания Microsoft и некоторые партнеры рекомендовали в целях предосторожности изолировать хозяина схемы (например, временно поместить его в отдельную сеть) для лучшего управления процессом обновления схемы. С тех пор специалисты службы поддержки пользователей Microsoft пришли к выводу, что в большинстве компаний такой подход скорее вызывает проблемы, чем устраняет. Поэтому специалисты Microsoft больше не рекомендуют отключать от сети хозяина схемы перед запуском adprep/forestprep.
Листинг 1. Текст ошибки в файле dcpromoui.log
Листинг 2. Поиск имени вспомогательного DC в файле dcpromoui.log
В этом разделе показан порядок подготовки кластерных объектов-компьютеров в доменных службах Active Directory (AD DS). Эту процедуру можно использовать, чтобы дать возможность пользователю или группе создавать отказоустойчивые кластеры, если у них нет разрешений на создание объектов-компьютеров в AD DS.
Когда вы создаете отказоустойчивый кластер с помощью мастера создания кластеров или Windows PowerShell, необходимо указать имя кластера. Если при создании кластера у вас достаточно разрешений, процесс создания кластера автоматически создает объект-компьютер в AD DS с соответствующим именем кластера. Этот объект называется объектом имени кластера или CNO. Посредством CNO при настройке кластерных ролей, использующих точки доступа клиентов, автоматически создаются виртуальные объекты-компьютеры (VCO). Например, если вы создали файловый сервер высокой надежности с точкой доступа клиента с именем FileServer1, CNO создаст соответствующий VCO в AD DS.
Существует возможность создания отсоединяемого от Active Directory кластера, в котором в AD DS не создаются объекты CNO или VCO. Эта возможность предназначена для определенных типов развертывания кластера. Дополнительные сведения см. в разделе о развертывании отсоединенного от Active Directory кластера.
Для автоматического создания CNO у пользователя, создающего отказоустойчивый кластер, должно быть разрешение на создание объектов-компьютеров для подразделения или контейнера, в которых размещаются серверы, которые войдут в кластер. Чтобы позволить пользователям и группам, не имеющим разрешения, создавать кластеры, пользователь с соответствующими разрешениями в AD DS (обычно администратор домена) может подготовить CNO в AD DS. Это также обеспечивает администратору домена больший контроль над именами, используемыми для кластера, и над тем, в каких подразделениях можно создавать кластерные объекты.
Шаг 2. Предоставление пользователю разрешений на создание кластера
Необходимо настроить разрешения, чтобы учетная запись пользователя, которая будет использоваться для создания отказоустойчивого кластера, имела полный доступ к CNO.
Минимальное требование для выполнения этого шага — членство в группе Операторы учета.
Вот как предоставить пользователю разрешения на создание кластера:
На странице "Пользователи и компьютеры Active Directory" в меню Вид убедитесь, что выбран пункт Дополнительные параметры.
Найдите и щелкните правой кнопкой мыши CNO, а затем выберите пункт "Свойства".
На вкладке Безопасность щелкните Добавить.
В диалоговом окне "Выбор пользователей, компьютеров или групп " укажите учетную запись пользователя или группу, для которой требуется предоставить разрешения, а затем нажмите кнопку "ОК".
Выберите добавленную учетную запись пользователя или группу и около пункта Полный доступ установите флажок Разрешить.
Рис. 2. Предоставление полного доступа пользователю или группе, которые будут создавать кластер
Щелкните ОК.
После завершения этого шага пользователь, которому вы предоставили разрешение, сможет создать отказоустойчивый кластер. Однако если CNO расположен в подразделении, до завершения вами шага 3 пользователь не сможет создавать кластерные роли, которые требуют точку доступа клиента.
Если CNO находится в контейнере компьютеров по умолчанию, администратор кластера может создать до 10 VCO без какой-либо дополнительной настройки. Чтобы добавить более 10 VCO, необходимо явно предоставить разрешение на создание объектов-компьютеров объекту имени кластера для контейнера компьютеров.
Сведения об исправлении
Существует исправление от корпорации Майкрософт. Однако данное исправление предназначено для устранения проблемы, описанной в этой статье. Применяйте это исправление только в тех случаях, когда наблюдается проблема, описанная в данной статье. Это исправление может проходить дополнительное тестирование. Таким образом если вы не подвержены серьезно этой проблеме, рекомендуется дождаться следующего пакета обновления, содержащего это исправление.
Если исправление доступно для скачивания, имеется раздел "Пакет исправлений доступен для скачивания" в верхней части этой статьи базы знаний. Если этот раздел не отображается, обратитесь в службу поддержки для получения исправления.
Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Для получения полного списка телефонов поддержки и обслуживания клиентов корпорации Майкрософт, или для создания отдельного запроса на обслуживание, посетите следующий веб-сайт Майкрософт:
http://support.microsoft.com/contactus/?ws=supportПримечание. В форме "Пакет исправлений доступен для скачивания" отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.
Предварительные условия
Для установки этого исправления необходимо наличие Windows Server 2012.
Сведения о реестре
Для использования исправления из этого пакета нет необходимости вносить изменения в реестр.
Необходимость перезагрузки
После установки исправления компьютер необходимо перезагрузить.
После установки инструкции
Это исправление позволяет предотвратить проблемы, описанные в разделе «Проблема». Если уже возникают эти проблемы, необходимо сбросить пароль на уязвимые имя ресурса. Но если он по-прежнему не работает, попробуйте сбросить пароль на имя кластера.
Примечаниенеобходимо войти в систему с учетной записью пользователя, обладающего правами на администрирование кластера и для сброса паролей в домене для выполнения следующих действий.
Для сброса пароля на уязвимые имя ресурса или имени кластера, выполните следующие действия:
Из диспетчера отказоустойчивости кластеров, найдите имя ресурса.
Щелкните ресурс правой кнопкой мыши и выберите команду Свойства.
На вкладке политики выберите при сбое ресурса не перезагружать компьютери нажмите кнопку ОК.
Щелкните правой кнопкой мыши на ресурсе, щелкните Дополнительные действияи выберите Симулировать сбой.
Если ресурс «имя» отображается «Ошибка», щелкните правой кнопкой мыши на ресурсе, щелкните Дополнительные действияи нажмите кнопку восстановить.
После имени ресурс находится в оперативном режиме, щелкните правой кнопкой мыши ресурс и выберите команду Свойства.
На вкладке политики выберите при сбое ресурса, попытки перезапуска на текущий узели нажмите кнопку ОК.
Сведения о замене исправлений
Это исправление не заменяет ранее выпущенные исправления.
Глобальная версия этого исправления устанавливает файлы с атрибутами, указанными в приведенных ниже таблицах. Дата и время для файлов указаны в формате UTC. Дата и время для файлов на локальном компьютере отображаются в местном времени с вашим текущим смещением летнего времени (DST). Кроме того, при выполнении определенных операций с файлами, даты и время могут изменяться.
Примечания к сведениям о файле Windows Server 2012Важно. Исправления для Windows Server 2012 и Windows 8 исправления включены в те же пакеты. Однако только «Windows 8» отображается на странице запрос исправления. Для получения пакета исправлений, который применяется к одной или обеих операционных систем, установите исправления, перечисленные в разделе «Windows 8» на странице. Всегда смотрите раздел "Информация в данной статье относится к следующим продуктам" статьи для определения фактических операционных систем, к которым применяется каждое исправление.
Файлы, относящиеся к определенному продукту, этапу разработки (RTM, SPn) и направлению поддержки (LDR, GDR) можно определить по номерам версий, как показано в следующей таблице.
Windows Server 2012
Windows Server 2012
Выпуски обновлений GDR содержат только те исправления, которые выпускаются повсеместно и предназначены для устранения распространенных крайне важных проблем. В обновления LDR входят также специализированные исправления.
Файлы МАНИФЕСТА (.manifest) и MUM (.mum), устанавливаемые для каждой среды, указаны отдельно в разделе «Дополнительные сведения о файлах» для системы Windows Server 2012»». Файлы MUM и MANIFEST, а также связанные файлы каталога безопасности (CAT) чрезвычайно важны для поддержания состояния обновленных компонентов. Файлы каталога безопасности, для которых не перечислены атрибуты, подписаны цифровой подписью корпорации Майкрософт.
Для всех поддерживаемых версий Windows Server 2012 для систем на базе x64
Я работаю в группе, которая занимается поддержкой отказоустойчивых кластеров, поэтому мне часто приходится выявлять и устранять неисправности. В этой статье будут описаны типичные проблемы, с которыми я сталкивался, с пояснением причин их возникновения и рекомендациями по их устранению
Как проверить, что все получилось?
Чтобы проверить, успешно ли создан объект имени кластера (CNO):
Откройте пункт "Пользователи и компьютеры Active Directory".
Разверните узел леса.
Откройте подразделение, в котором создана учетная запись, и убедитесь в ее наличии в списке.
Windows Server 2012 Datacenter Windows Server 2012 Datacenter Windows Server 2012 Essentials Windows Server 2012 Foundation Windows Server 2012 Foundation Windows Server 2012 Standard Windows Server 2012 Standard Еще. Меньше
Важно - загрузить это исправление предотвращает проблемы, описанные в разделе «Проблема». Если уже возникают эти проблемы, необходимо сбросить пароль на уязвимые имя ресурса или имени кластера, как описано в инструкции после установки.
Ошибка делегирования DNS
Экран 1. Ошибка делегирования DNS |
До появления Server 2008 многие проблемы с AD были вызваны внутренними неполадками в инфраструктуре DNS, в частности отсутствующими или неправильными записями делегирования DNS. Одной из целей специалистов Microsoft при совершенствовании установки служб AD DS в Server 2008 было помочь потребителям в начальной настройке правильной инфраструктуры DNS, а затем облегчить обслуживание данной конфигурации.
- утилита Dcpromo настроена для установки роли DNS-сервера;
- слишком мало отношений делегирования существует между DNS-серверами и непосредственной родительской зоной DNS и поддоменом, в котором устанавливается новый DC;
- устанавливаемый DC не может создать делегирование поддомену DNS на DNS-сервере для родительской зоны.
Dcpromo пытается создать делегирование, чтобы компьютеры в других доменах могли распознавать запросы DNS для узлов, в том числе контроллеров домена и компьютеров — членов домена, в поддомене DNS. Dcpromo может автоматически создавать такие отношения делегирования только на DNS-серверах Microsoft; попытка завершится неудачей, если родительская зона домена DNS находится на сторонних DNS-серверах, таких как BIND.
Чтобы организовать делегирование на полномочных DNS-серверах в родительском домене, должны быть выполнены следующие условия.
- На родительском DNS-сервере должна функционировать служба Microsoft DNS Server.
- DNS-сервер Microsoft в родительском домене должен быть подключен к сети и доступен с устанавливаемого контроллера домена.
- Пользователь, запускающий утилиту Dcpromo на устанавливаемом контроллере домена, должен иметь учетные данные Domain Admins, Enterprise Admins или DNS Admin в родительской зоне DNS.
Виртуальные DC и возврат USN
Только поддерживаемые решения резервного копирования, такие как Windows Server Backup, могут быть использованы для восстановления контроллера домена. Недавно компания Microsoft пересмотрела рекомендации по запуску контроллеров домена на виртуальных машинах, в частности объяснено функционирование USN и способы предотвращения возврата USN. Благодаря этим изменениям информация представлена в более краткой и ясной форме, и администраторам будет проще избежать проблем.
Проблема 5
Чтобы узел был осведомлен о том, какие узлы являются активными участниками кластера (то есть о текущем членстве), применяется ряд периодических контрольных сигналов, передаваемых между узлами по сети. Эти пакеты сигналов представляют собой UDP-датаграммы, следующие через порт 3343.
Каждый пакет включает регистрационный номер, по которому отслеживается факт приема пакета. Это работает следующим образом: узел Node1, отправляющий регистрационный номер 1111, ожидает ответного пакета, включающего 1111. Эти действия совершаются между всеми узлами каждую секунду. Если узел Node1 не получает ответного пакета, он отправляет следующий по порядку регистрационный номер (1112), и т.д.
По умолчанию, если узел не получает пять контрольных сигналов в течение пяти секунд, WSFC устанавливает факт отказа узла. Активный узел в кластере отправляет пакет на узел, где установлен отказ, чтобы завершить работу службы кластера, и регистрирует событие 1135 в журнале событий системы (см. экран 7).
Экран 7. Событие 1135 в журнале событий системы |
Такое событие может быть вызвано несколькими причинами, многие из которых связаны с блокировкой связи через порт 3343:
1. Отказ сетевого оборудования.
2. Устаревший драйвер или устаревшая прошивка сетевого адаптера.
3. Сетевая задержка.
4. Протокол IPv6 разрешен на серверах, но параметры брандмауэра Windows выключают следующие разрешения для входящего и исходящего трафика:
- основы сетей – объявление поиска соседей;
- основы сетей – запрос поиска соседей.
5. Настройка коммутаторов, брандмауэров или маршрутизаторов не допускает прохождения трафика данных UDP-датаграмм.
6. Проблемы производительности (зависания, задержки и прочее).
7. Неправильно настроенные параметры буфера приема у драйвера сетевого адаптера.
Первым делом я всегда проверяю счетчик отброшенных принятых пакетов в составе объекта производительности сетевого интерфейса в окне системного монитора. Этот счетчик отслеживает число входящих пакетов, которые были отброшены, хотя и не было зафиксировано каких-либо ошибок, препятствующих их передаче протоколу верхнего уровня. Одна из возможных причин – необходимость освободить место в буфере.
Для добавления счетчика отброшенных принятых пакетов в окне системного монитора щелкните правой кнопкой на дисплее и выберите «Добавить счетчики». В открывшемся окне добавления счетчиков укажите нужный компьютер, выполните прокрутку и выберите счетчик «Отброшено принятых пакетов». В выпадающем списке «Экземпляры выбранного объекта» выберите нужный сетевой адаптер и нажмите «Добавить» (см. экран 8).
Добавив счетчик, проверьте его среднее, минимальное и максимальное значения. Если есть значения больше нуля, это указывает на необходимость настройки буфера приема для сетевого адаптера. Проконсультируйтесь с производителем сетевого адаптера по поводу рекомендуемых параметров. Может потребоваться перезагрузка.
В отказоустойчивом кластере Windows Server 2012 R2 можно воспользоваться мастером проверки конфигурации для выполнения проверки сетевого взаимодействия. Этот тест позволяет проверить возможность информационного обмена между узлами через порт 3343. Если есть проблемы связи, то будет выдана соответствующая ошибка с указанием возможной причины.
Причина
Эти проблемы возникают при выполнении отказоустойчивом кластере Windows Server 2012 которого является членом домена Active Directory, который имеет домен функциональный уровень Windows Server 2003. Это происходит в результате rc4 hmac ключей на контроллере домена и на стороне кластеров для объекта виртуального компьютера (VCO) отличаются. Если билет шифруется с использованием шифрования rc4 hmac, сбои расшифровки билетов. Кроме того кластер становится недоступным для любого компьютера, который использует ключи rc4 hmac.
Предварительная подготовка CNO в AD DS
На компьютере с установленными средствами AD DS из средств удаленного администрирования сервера или на контроллере домена откройте Пользователи и компьютеры Active Directory. Для этого на сервере запустите диспетчер сервера, а затем в меню "Сервис" выберите Пользователи и компьютеры Active Directory.
Чтобы создать подразделение для объектов компьютера кластера, щелкните правой кнопкой мыши доменное имя или существующее подразделение, наведите указатель мыши на "Создать" и выберите подразделение. В поле "Имя" введите имя подразделения и нажмите кнопку "ОК".
В дереве консоли щелкните правой кнопкой мыши подразделение, в котором нужно создать CNO, наведите указатель мыши на "Создать" и выберите " Компьютер".
В поле "Имя компьютера " введите имя, которое будет использоваться для отказоустойчивого кластера, а затем нажмите кнопку "ОК".
Это имя кластера, которое пользователь, создающий кластер, укажет в мастере создания кластеров на странице Точка доступа для администрирования кластера или укажет как значение параметра –Name для командлета New-Cluster Windows PowerShell.
Рекомендуется щелкнуть правой кнопкой мыши только что созданную учетную запись компьютера, выбрать пункт "Свойства" и выбрать вкладку "Объект ". На вкладке "Объект" установите флажок "Защитить объект от случайного удаления " и нажмите кнопку "ОК".
Учетную запись необходимо отключить, чтобы во время создания кластера соответствующий процесс подтвердил, что учетная запись не используется в данный момент существующим компьютером или кластером в домене.
Рис. 1. Отключенный CNO в примере подразделения кластеров
Проблема 2
При попытке перевести ресурс сетевого имени сети на основе Windows Server 2012 отказоустойчивого кластера, попытка завершается неудачей. Кроме того в журнале системы регистрируются следующие события:
Событие с кодом 1228
Ресурс сетевого имени кластера «Имя кластера» ошибка Включение имя сети на этом узле. Причина сбоя: «Не удалось получить маркер входа в систему». Код ошибки: "1326". Может потребоваться ресурс сетевого имени автономного и еще раз, чтобы повторить попытку.
Событие с кодом 1196
Ресурс сетевого имени кластера «Имя кластера» сбой при регистрации одного или несколько связанных с ним имена DNS по следующей причине: недопустимый дескриптор. Убедитесь, что сетевые адаптеры, связанные с зависимые ресурсы IP-адресов настроены по крайней мере один DNS-сервер доступен.
Кроме того может появиться следующее в журнал кластера.
Имя сети INFO [РЕСУРС]: [NNLIB] LsaCallAuthenticationPackage успех вместе с запросом 82, результат размер 0 (статус: 0, подробный: 0)
Имя сети ПРЕДУПРЕЖДАТЬ [РЕСУРС]: [NNLIB] LogonUserEx завершается неудачей для пользователя E0117-C1$: 1326 (useSecondaryPassword: 0)
Имя сети ПРЕДУПРЕЖДАТЬ [РЕСУРС]: [NNLIB] LogonUserEx завершается неудачей для пользователя E0117-C1$: 1326 (useSecondaryPassword: 1)
Сетевое имя < имя кластера >ПРЕДУПРЕЖДАТЬ [РЕСУРС]: AccountAD: медленная операция имеет исключение ERROR_INVALID_HANDLE(6) «из-за»:: ImpersonateLoggedOnUser (GetToken()) "
Сетевое имя < имя кластера >ERR [РЕСУРС]: Поток Online ошибка: ERROR_SUCCESS(0) "из-за «Инициализация конфигурации сетевое_имя «Имя кластера» произошла ошибка 6.»
Сетевое имя < имя кластера >INFO [РЕСУРС]: Все ресурсы. Очистка.
Ошибка сети [RHS] для ресурса имени кластера не удалось. Ошибка 6 -> обработки является недопустимым.
Проблема 6
В листинге приведен сценарий Windows PowerShell, позволяющий выявить узел, утративший экземпляр Cluster WMI.
Установив проблемный узел, можно ввести команду
Наиболее распространенной причиной утраты Cluswmi.mof узлом является устаревший способ решения проблем WMI. Для устранения неполадок WMI администраторы обычно используют команду Mofcomp.exe *.mof, позволяющую скомпилировать все файлы Managed Object Format (MOF) в репозиторий WMI. Однако дело в том, что существует довольно много файлов удаления для различных ролей и компонентов Windows, включая Cluster WMI. Поэтому файл Cluswmi.mof, устанавливаемый с помощью этой команды, впоследствии удаляется. Правильный способ восстановления репозитория WMI – с использованием команды Winmgmt.exe.
Решение
Чтобы устранить эту проблему, установите накопительный пакет обновления 2889784 или установить исправление, описанное в данной статье.
Дополнительные сведения о получении накопительного пакета обновления 2889784 щелкните следующий номер статьи базы знаний Майкрософт:
2889784 Windows Server 2012, Windows 8 и Windows RT накопительный пакет обновления: Ноябрь 2013
Кроме того, корпорация Майкрософт рекомендует обновить функциональный уровень домена для домена Active Directory, отказоустойчивый кластер Windows Server 2012 подключенный к Windows Server 2003 до более поздней версии Windows Server.
Проблема 1
Служба кластеров при запуске обнаруживает сети, в которые входит узел, и для каждой сети определяет сетевые адаптеры. Одна из типичных неполадок связана с тем, что отказоустойчивая кластеризация Windows Server (WSFC) допускает использование для одной сети только одного сетевого адаптера. Все прочие адаптеры этой сети игнорируются.
Предположим, что администратор настроил узел с двумя сетевыми адаптерами для одной сети:
Сетевой драйвер кластера (Netft.sys) для каждой сети будет использовать только один сетевой адаптер (или группу). Поэтому при данной конфигурации сеть кластера Cluster Network 1 (10.10.10.0/16) будет задействовать только сетевой адаптер Card1, тогда как сетевой адаптер Card2 будет игнорироваться, то есть не будет применяться для связи между узлами. Поскольку работает только одна сеть, при выходе Card1 из строя или утрате сетевого соединения узел не сможет взаимодействовать с другими узлами. Это единственная точка отказа. Чтобы избежать подобной ситуации, кластер следует настраивать так, чтобы между узлами существовало, как минимум, два сетевых пути. В этом случае при отказе одного из сетевых адаптеров связь между узлами будет осуществляться через другой сетевой адаптер.
Ошибку легче предупредить
Как известно, предупредить ошибку легче, чем исправлять ее последствия. Поэтому в заключение повторю простое правило: регулярно актуализируйте состояние своих систем, применяя все обновления и исправления, касающиеся безопасности. Команда разработчиков отказоустойчивой кластеризации в Microsoft опубликовала материалы с перечнями исправлений, которые рекомендуется применить на всех кластерах. Каждой версии Windows посвящена отдельная публикация:
Материалы обновляются по мере необходимости, поэтому всегда актуальны. Замечу, что в них перечислены не все исправления, а лишь самые критичные для обеспечения стабильной работы и наиболее востребованные, исходя из числа обращений в службу поддержки Microsoft.
Листинг. Сценарий PowerShell для определения узлов с отсутствующим экземпляром Cluster WMI
Ошибки, связанные с Adprep
Adprep — утилита для подготовки существующей среды Active Directory (AD) для первого DC, функционирующего с новой операционной системой, например Server 2008 R2. Если все контроллеры домена в среде AD работают с Server 2008 или Windows 2003 и требуется добавить первый DC с операционной системой Server 2008 R2, необходимо выполнить определенные команды Adprep.
- Выполните adprep/forestprep на хозяине схемы.
- Выполните adprep/domainprep на каждом хозяине инфраструктуры домена.
- Если предполагается установить доступный только для чтения DC (RODC — новшество Server 2008), следует также выполнить adprep/rodcprep для каждого домена с RODC.
Этот достаточно простой процесс подробно описан в Интернете, но тем не менее у администраторов часто возникают вопросы:
- какие именно действия выполняет Adprep?
- как убедиться, что все необходимые команды Adprep выполнены успешно?
- как исправлять возникающие ошибки?
При запуске Adprep необходимо учитывать следующие важные факторы.
Если подготовиться к возможным проблемам и выполнять рекомендации, приведенные в указанных выше статьях, то, скорее всего, сбоев удастся избежать. Однако в некоторых случаях в ходе выполнения Adprep могут возникать следующие ошибки.
Ошибка The Specified User Already Exists
Чаще всего эта ошибка указывает на то, что имя узла повышаемого сервера — такое же, как у другого контроллера домена. Для устранения этой проблемы выполните следующие шаги.
- Если выполняется замена ранее пониженного DC новым контроллером домена с тем же именем, обязательно удалите метаданные старого DC. В Server 2008 и более новых версиях самый простой способ удаления метаданных — через оснастки AD. При необходимости можно воспользоваться и старым методом — Ntdsutil.
- Если по-прежнему происходят сбои Dcpromo с этой ошибкой, выясните в файле dcpromoui.log имя исходного DC (он же вспомогательный DC), используемого новым DC для репликации. Найдите в файле раздел, который начинается с метки A в листинге 2. Имя исходного DC показано во фрагменте с меткой B.
- Убедитесь, что исходный DC выполнил входящую репликацию удаления метаданных DC (то есть конфликтующих учетной записи компьютера DC и объектов параметров NTDS). Если учетная запись контроллера домена все еще существует, определите причину:
- простая задержка репликации; например, DC находится на расстоянии нескольких переходов от DC, запустившего операцию очистки метаданных;
- сбой входящей репликации на вспомогательном DC или на исходном DC, с которого вспомогательный DC получает изменения;
- вспомогательный DC в «сайте задержки» преднамеренно настроен на входящую репликацию изменений в AD с задержкой.
У ошибки могут быть и другие причины, кроме конфликта учетных записей компьютера. В следующих статьях Microsoft рассматриваются некоторые из них:
Таблица 1. Возможные строки расширения ошибок |
Еще одна распространенная причина сбоя установки AD заключается в том, что группе Administrators не назначено право Enable computer and user accounts to be trusted for delegation («Разрешение доверия к учетным записям компьютеров и пользователей при делегировании»). Это право — параметр групповой политики, включенный для группы Administrators по умолчанию в политике контроллеров домена. Если DC выбран в качестве партнера репликации в ходе повышения уровня реплицируемого DC, выбранному DC требуется доступ к ресурсам повышаемого компьютера. Если право Enable computer and user accounts to be trusted for delegation не назначено группе безопасности Administrators, то каждый запрос доступа к ресурсу завершается неудачей с пояснением «отказано в доступе», как показано на экране 2.
Экран 2. Ошибка «отказано в доступе» |
Чтобы устранить ошибку, используйте консоль управления групповой политики (GPMC) и инструмент Group Policy Results (Gpresult) для проверки, назначено ли группе Administrators право Enable computer and user accounts to be trusted for delegation в политике Default Domain Controllers Policy. Путь в редакторе групповой политики — \Computer Configuration\Policies\Windows Settings\SecuritySettings\Local Policies\UserRights Assignment\Enable computer and user accounts to be trusted for delegation.
После того как DC начинает работать с 2008 R2, можно запустить анализатор AD DS Best Practices Analyzer (BPA) для обнаружения любых ошибок в настройках политики. Соответствующее правило BPA не входит в изначальный набор правил, но имеется в дополнительном наборе правил, поставляемом через службу Windows Update. Это правило применяется к DC, работающему с Server 2008 R2.
При запуске AD DS BPA другое правило из того же дополнительного набора поможет предотвратить две типичные ошибки в настройках групповой политики, которые являются коренными причинами отказа репликации DC: непредоставление права Access this computer from the network («Доступ к компьютеру из сети») группам безопасности Administrators, Enterprise Domain Controllers или Authenticated Users либо назначение группам безопасности Enterprise Domain Controllers, Everyone, Administrators или Authenticated Users права Deny access to this computer from network («Запрет доступа к компьютеру из сети»). Отказ может случиться на любом DC, пытающемся выполнить репликацию из DC с одной из упомянутых выше настроек. Пользователи и компьютеры также могут столкнуться с отказами при применении объектов групповой политики (GPO).
Чтобы устранить эту ошибку, убедитесь в анализаторе BPA, что контроллеры домена назначили это право соответствующему участнику безопасности. Используйте настройки GPMC и Gpresult из таблицы 2, чтобы проверить правильность параметров групповой политики.
Таблица 2. Параметры GPMC и Gpresult |
Проблема 2
Вторую типичную проблему проще всего раскрыть с помощью сценариев. Опишем ее на примере двух различных конфигураций кластера: односайтовой и многосайтовой.
Односайтовый кластер. Предположим, что администратор решил изменить конфигурацию кластера, установив две сети между узлами Node1 и Node2. На узле Node1 он поменял IP-адреса и маски подсети сетевых адаптеров:
Кроме того, администратор поменял IP-адреса узла Node2 (192.168.0.2 и 10.10.10.2). При этом на узле Node1 в кластере он добавил группу файлового сервера, назначив ей IP-адрес 192.168.0.15.
Затем администратор протестировал кластер, чтобы убедиться в успешном переходе группы файлового сервера на узел Node2 при отработке отказа. Однако IP-адрес группы файлового сервера не виден в сети, то есть группа находится в автономном состоянии. В журнале событий системы регистрируется событие 1069, описание которого указывает на отказ ресурса с этим IP-адресом.
Причина отказа становится очевидной, если воспользоваться командой PowerShell Get-ClusterLog для вывода журнала кластера. Для этого достаточно ввести следующий набор символов:
Команда инициирует создание журнала кластера на каждом узле. Для построения журнала кластера только на одном узле можно добавить параметр -Node и указать имя узла. Можно также добавить параметр -TimeSpan для создания журнала только за последние x минут. Например, приведенная ниже команда предписывает построить журнал кластера на узле Node2 за последние 15 минут:
В результатах, представленных на экране 1, указано состояние «status 5035.».
Экран 1. Информация о состоянии 5035 в файле журнала кластера |
Создавая ресурс с IP-адресом, можно указать сеть, которая будет использоваться для него. Если эта сеть не будет существовать на узле, куда данный ресурс перейдет при отработке отказа, то WSFC не поменяет сеть, используемую ресурсом. В данном примере, при том IP-адресе, который указал администратор, и маске подсети, применяемой этим IP-адресом, группа файлового сервера сможет работать только по сети Cluster Network 1 (192.168.0.0/24).
Многосайтовый кластер. В случае многосайтового кластера каждый узел обычно имеет собственную сеть со своим IP-адресом. При первоначальном создании кластера и его ролей с помощью мастера создания ресурсов вам предлагается указать IP-адрес для сетей каждого из узлов, настроенных для клиентского доступа (см. экран 2).
Экран 2. Создание многосайтового кластера |
Мастер создания ресурсов, создавая IP-адреса и назначая имя сети, автоматически присваивает параметру зависимости этого имени сети значение «или». Это означает, что если один из IP-адресов в сети, имя также видно в сети. Создавая группы или ресурсы перед добавлением узлов из других сетей, необходимо вручную создавать эти вторичные IP-адреса и добавлять зависимость «или».
Ошибки, связанные с Adprep
Adprep — утилита для подготовки существующей среды Active Directory (AD) для первого DC, функционирующего с новой операционной системой, например Server 2008 R2. Если все контроллеры домена в среде AD работают с Server 2008 или Windows 2003 и требуется добавить первый DC с операционной системой Server 2008 R2, необходимо выполнить определенные команды Adprep.
- Выполните adprep/forestprep на хозяине схемы.
- Выполните adprep/domainprep на каждом хозяине инфраструктуры домена.
- Если предполагается установить доступный только для чтения DC (RODC — новшество Server 2008), следует также выполнить adprep/rodcprep для каждого домена с RODC.
Этот достаточно простой процесс подробно описан в Интернете, но тем не менее у администраторов часто возникают вопросы:
- какие именно действия выполняет Adprep?
- как убедиться, что все необходимые команды Adprep выполнены успешно?
- как исправлять возникающие ошибки?
При запуске Adprep необходимо учитывать следующие важные факторы.
Если подготовиться к возможным проблемам и выполнять рекомендации, приведенные в указанных выше статьях, то, скорее всего, сбоев удастся избежать. Однако в некоторых случаях в ходе выполнения Adprep могут возникать следующие ошибки.
Проблема 3
Событие с кодом 21502
Сбой при динамической миграции «Имя виртуальной Машины». Сбой операции миграции виртуальной машины для «Имя виртуальной Машины» в источник миграции «Имя узла»
Не удалось установить подключение для миграции виртуальной машины с узла «Имя узла» службы управления виртуальными машинами: попытка входа не удалась (0x8009030C).
Не удалось проверить подлинность соединения для миграции виртуальной машины на узле источника службы управления виртуальными машинами: попытка входа не удалась (0x8009030C).
Назначение разрешений сетевому объекту кластера
Откройте пункт "Пользователи и компьютеры Active Directory".
Если "Дополнительные параметры" отключены, включите их. Для этого откройте меню Вид, затем выберите пункт Дополнительные параметры.
Щелкните правой кнопкой мыши новую учетную запись компьютера и выберите Свойства.
В свойствах на вкладке Безопасность щелкните Добавить, чтобы добавить учетную запись компьютера для первого узла, который будет добавлен в DAG, или добавить Exchange доверяемую подсистему USG:
Проблема 1
недоступен. Может не иметь разрешения на использование этого сетевого ресурса. Обратитесь к администратору этого сервера, чтобы выяснить, если имеются разрешения на доступ. Ошибка входа в систему: Неверное имя конечной учетной записи.
В то же время в журнале событий на компьютере под управлением Windows XP или ОС Windows Server 2003 регистрируется следующее событие:
Тип события: ошибка
Источник события: Kerberos
Категория события: нет
Код события: 4
Файловый ресурс общего доступа можно получить доступ при подключении к нему с помощью IP-адреса.
Кроме того, «SMB:KrbError: KRB_AP_ERR_MODIFIED (41) R; Сеанс настройки Andx, Krb5Error (0x300)» для ответа сервера при установке сеанса SMB в трассировку сети.
Проблема с Windows 7 и более поздних версий клиентских компьютеров не отображается, если принудительно использовать rc4 hmac.
Симптомы
Проблема 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. Соответствующая настройка прав позволит вам создать кластер.
Экран 4. Ошибка проверки настроек Active Directory |
Все другие ресурсы с сетевыми именами в кластере ассоциированы с объектами виртуальных компьютеров (VCO), создаваемыми в том же OU, что и CNO. Следовательно, при назначении ролей в кластере необходимо указать CNO с соответствующими правами (просмотр и создание) в отношении OU, поскольку CNO формирует все VCO в кластере. В противном случае новая роль будет находиться в состоянии сбоя. Тогда в журнале появится событие 1194 (см. экран 5).
Экран 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 могла выполнять сброс при необходимости.
Читайте также: