Управление групповыми политиками в организации. Часть 2

Введение


В предыдущей части данной статьи, вы узнали о средстве, при помощи которого корпорация Microsoft позволяет рационально управлять всей инфраструктурой вашего предприятия, начиная от незначительных подразделений и групп, и заканчивая сайтами и доменами, а именно об оснастке «Управление групповой политикой». Вы узнали о том, как можно открыть данную оснастку, а также о создании, редактировании и удалении объектов групповой политики. Для правильного управления вашей организации одного лишь создания объектов GPO недостаточно, так как объект групповой политики – это только набор параметров настроек конфигурации пользователя или компьютера, которые обрабатываются расширениями клиентской стороны (Client-Side Extension - CSE). Чтобы ваши объекты GPO распространялись на клиентов, нужно настраивать связи объектов групповых политик с сайтами, доменами или подразделениями. В этой статье вы узнаете о связях объектов групповых политик.


Связывание объектов GPO


Как было указано ранее, для правильного управления клиентов, объекты групповых политик должны быть настроены на определенные параметры политик и связаны с доменом, сайтом или подразделением Active Directory. Также вы можете указать определенную группу или пользователей, предназначенных для области применения указанного GPO. Вы можете сначала создать все нужные для вас объекты GPO в контейнере «Объекты групповой политики», а потом их связать с нужными подразделениями, доменами или сайтами.

Необходимо помнить, что объект групповой политики, который связан с сайтом, влияет на все компьютеры в указанном сайте независимо от домена, которому принадлежат ваши компьютеры. В связи с этим, для того чтобы применить указанные настройки объектов групповых политик к множеству доменов в лесу, можно связать объекты GPO с сайтом. Такие объекты будут храниться на контроллерах домена. Для создания и привязки объектов групповых политик, у вашей доменной учетной записи должны быть соответствующие права. По умолчанию, за создание и управление объектов GPO отвечают только пользователи, которые входят в группы администраторов домена, администраторов предприятия и владельцев-создателей объектов групповой политики.

Для того чтобы связать существующий объект групповой политики, выполните следующие действия:
1. Откройте консоль «Управление групповой политикой»;
2. Выберите подразделение, домен или сайт, для которого будет создана связь с существующим объектом групповой политики;
3. Нажмите на нем правой кнопкой мыши и из контекстного меню выберите команду «Связать существующий объект групповой политики»;
4. В диалоговом окне «Выбор объекта групповой политики» выделите объект GPO, который хотите привязать к своему подразделению и нажмите на кнопку «ОК», как показано ниже:

Рис. 1. Диалоговое окно «Выбор объекта групповой политики»

Также у вас есть возможность привязать к домену, сайту или подразделению еще не существующий объект групповой политики. В этом случае, помимо связи вам также предстоит создание нового объекта GPO. Для этого выполните следующие действия:

1. Откройте консоль «Управление групповой политикой»;
2. Выберите подразделение, домен или сайт, для которого будет создан и привязан новый объект групповых политик;
3. Нажмите на нем правой кнопкой мыши и из контекстного меню выберите команду «Создать объект групповой политики в этом домене и связать его…»;
4. В диалоговом окне «Новый объект групповой политики» введите название нового объекта, например, «Ограничения доступа к медиа приложениям» и нажмите на кнопку «ОК»;

Рис. 2. Создание нового объекта групповой политики вместе со связью

5. После нажатия на кнопку «ОК» объект групповой политики будет создан вместе со связью. Для этого объекта нужно будет еще настроить определенную конфигурацию, нажав на нем правой кнопкой мыши и из контекстного меню выбрав команду «Изменить», о которой рассказывалось в предыдущей части статьи.

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

Начальная область действия объекта групповой политики назначается при привязке данного объекта к указанному контейнеру. Для того чтобы увидеть контейнеры, к которым привязан существующий объект, выберите данный объект групповой политики и перейдите на вкладку «Область», как показано на следующей иллюстрации:

Рис. 3. Область действия объекта групповой политики

Вы можете просмотреть все измененные параметры политик для конкретного объекта групповой политики. Для этого выполните следующие действия:
1. В консоли управления групповой политикой выберите объект групповой политики;
2. Перейдите на вкладку «Параметры»;
3. В отобразившемся отчете разверните параметры политик, которые хотите просмотреть. После нажатия на ссылку «Показать все», будут отображены все измененные параметры данного объекта GPO

Рис. 4. Параметры объекта групповой политики

4. Вы можете сохранить данный отчет для дальнейшего изучения или анализа. Для этого нажмите правой кнопкой мыши на отчете и из контекстного меню выберите команду «Сохранить отчет». В диалоговом окне «Сохранение отчета объекта групповой политики» выберите папку, в которую хотите сохранить отчет, в поле «Имя файла» введите название отчета (по умолчанию название отчета совпадает с наименованием объекта GPO) и нажмите на кнопку «Сохранить». Отчет можно сохранять как с расширением HTML, так и XML.

Принудительные связи объектов групповых политик

При создании связей объектов групповых политик для некоторых контейнеров у вас могут возникнуть конфликты параметров политик. Скажем, для подразделения «Группы» у вас есть три связанных объекта GPO и в двух из них указаны разные значения одного и того же параметра политики. Например, в объекте групповой политики «Ограничение доступа к медиа приложениям» для политики «Не запускать Windows Media Center» установлено значение «Включено», а в объекте «Конфигурация конференц-зала» - наоборот, установлено значение «Отключено». В этом случае указывается параметр политики, который будет применен к клиентам при помощи приоритета объектов GPO, причем объект с более высоким уровнем приоритета будет иметь преимущество над теми объектами групповой политики, чьи приоритеты ниже.

Приоритеты можно найти в консоли «Управление групповой политикой» на вкладке «Наследование групповой политики» для выбранного контейнера, как показано ниже:

Рис. 5. Наследование групповой политики

На предыдущей иллюстрации видно, что на подразделение «Группы» распространяются четыре объекта групповых политик, причем у объекта групповой политики с наименьшим значением самый высокий приоритет. Т.е., в данном случае, значения параметров политик объекта групповой политики «Политика аудита» доминирует над всеми остальными объектами GPO для данного подразделения. Но если в объекте групповой политики с наивысшим приоритетом значение для какого-либо параметра не задано, то будут применяться параметры политики с объекта групповой политики с более низким приоритетом. Наследование и делегирование групповых политик будут подробно рассмотрены в одной из следующих статей.

Оснастка «Управление групповой политикой» позволяет включать принудительную связь объекта групповой политики. При включении принудительной связи для объекта групповой политики, данный объект получит наивысший приоритет по отношению к остальным объектам, как выбранного контейнера, так и для всех дочерних. Для того чтобы установить принудительную связь для объекта групповой политики, выполните следующие действия:

1.Выберите контейнер, к которому привязаны несколько объектов групповых политик;
2. Перейдите на вкладку «Связанные объекты групповой политики», выберите объект, для которого хотите установить принудительную связь, нажмите на нем правой кнопкой мыши и из контекстного меню выберите команду «Принудительный»;

Рис. 6. Установка принудительной связи
3. В диалоговом окне «Управление групповой политикой» нажмите на кнопку «ОК»;

4. После установки принудительной связи, на вкладке «Связанные объекты групповой политики» для данного объекта появится значок в виде висячего замка, который обозначает принудительное включение связи. Перейдите на вкладку «Наследование групповой политики». Здесь вы можете увидеть результирующий приоритет объектов групповых политик, где в столбце «Приоритет» установленная принудительная связь будет отображаться сверху с пометкой «(Принудительный)».

Рис. 7. Принудительная связь объекта групповой политики

Отключение объектов групповых политик

При необходимости, для определенного объекта групповой политики вы можете запретить изменение параметров политик для узлов «Конфигурация компьютера» или «Конфигурация пользователя» средствами изменения состояния объекта GPO. Для этого выберите объект групповой политики, перейдите на вкладку «Таблица» и из раскрывающегося списка «Состояние GPO» выберите один из следующих параметров:

Рис. 8. Выбор состояния объекта групповой политики

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

Параметры конфигурации компьютера отключены. В этом случае, во время обновления политик GPO, будут обрабатываться только политики конфигурации пользователя. В свою очередь, параметры конфигурации компьютера будут отключены;
Параметры конфигурации пользователя отключены. В этом случае, во время обновления политик GPO, будут обрабатываться только политики конфигурации компьютера. В свою очередь, параметры конфигурации пользователя будут отключены;

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

Отключение связи

Если вы случайно неправильно создали связь для объекта групповой политики, не стоит волноваться. Всегда такую связь можно удалить без нанесения ущерба самому объекту групповой политики. После удаления связи, объект GPO из контейнера «Объекты групповой политики» остается. Вы можете полностью удалить связь или отключить ее. Для удаления связи объекта групповой политики, выполните следующие действия:
1. Откройте контейнер, для которого вам нужно удалить объект GPO;
2. Выберите удаляемый объект групповой политики и нажмите на нем правой кнопкой мыши и в контекстном меню выберите команду «Удалить»;
3. В диалоговом окне «Управление групповой политикой» нажмите на кнопку «ОК».

Для того чтобы отключить объект групповой политики выберите отключаемый объект GPO и из контекстного меню снимите флажок с команды «Связь включена». После того как вы отключите связь объекта GPO, изменится и его область действия, которая больше не будет применяться для данного контейнера до тех пор, пока вы самостоятельно не включите ее. При отключении связи, значок данного объекта выглядит более прозрачным.

Заключение

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

источник

Управление групповыми политиками в организации. Часть 1

Введение


В любой организации системные администраторы обязаны обеспечить для пользователей и компьютеров своего предприятия безопасные настройки, которыми можно централизовано управлять и развертывать. Обычно в организациях вся конфигурация определяется, обновляется и распространяется непосредственно при помощи объектов групповой политики. Именно объекты групповой политики позволяют вам рационально управлять всей инфраструктурой вашего предприятия, начиная от незначительных подразделений и групп и заканчивая сайтами и доменами. В домене Active Directory все объекты групповой политики создаются и управляются при помощи единой административной оснастки консоли управления Microsoft – «Управление групповой политикой». Именно об использовании данной оснастки пойдет речь в текущей статье.


Открытие оснастки и изменение пользовательского интерфейса

Оснастка «Управление групповой политикой» устанавливается на сервер вместе с ролью «Доменные службы Active Directory» (AD DS), но если у вас по какой-то причине не удается ее найти, то всегда данную оснастку можно заново установить. Для того чтобы повторно установить текущую оснастку, в «Диспетчере сервера», в узле «Сводка компонентов» перейдите по ссылке «Добавить компонент». Выберите компонент «Управление групповой политикой» в диалоговом окне «Мастер добавления компонентов» и следуйте инструкциям мастера. По завершению установки закройте мастер установки.

Также есть альтернативный способ установки данного компонента – использование командной строки и утилиты управления конфигурацией сервера. В командной строке, запущенной с правами администратора введите ServerManagerCmd -install gpmc. При желании вы можете вывести результат установки в xml файл, используя параметр –resultPath.

Для того чтобы открыть оснастку «Управление групповой политикой», выполните любое из следующих действий:
Нажмите на кнопку «Пуск», выберите меню «Администрирование», а затем откройте «Управление групповой политикой»;
Воспользуйтесь комбинацией клавиш Win+R для открытия диалога «Выполнить». В диалоговом окне «Выполнить», в поле «Открыть» введите gpmc.msc и нажмите на кнопку «ОК»;
Нажмите на кнопку «Пуск» для открытия меню, в поле поиска введите Управление групповой политикой и откройте приложение в найденных результатах;
Откройте «Консоль управления MMC». Для этого нажмите на кнопку «Пуск», в поле поиска введите mmc, а затем нажмите на кнопку «Enter». Откроется пустая консоль MMC. В меню «Консоль» выберите команду «Добавить или удалить оснастку» или воспользуйтесь комбинацией клавиш Ctrl+M. В диалоге «Добавление и удаление оснасток» выберите оснастку «Управление групповой политикой» и нажмите на кнопку «Добавить», а затем нажмите на кнопку «ОК».

На следующей иллюстрации изображена оснастка «Управление групповой политикой»:

Рис. 1. Оснастка «Управление групповой политикой»

Содержимое оснастки «Управление групповой политикой» предоставляет множество средств, предназначенных для обеспечения централизованного управления инфраструктурой организации. Но если вас не устраивает интерфейс данной оснастки, вы можете его изменить, используя функционал редактирования параметров пользовательского интерфейса. Для того чтобы изменить отображение некоторых элементов оснастки, откройте меню «Вид» и выберите команду «Параметры». В диалоговом окне «Параметры» вы можете настроить элементы, параметры которых располагаются в следующих вкладках:
Вкладка «Столбцы». На этой вкладке вы можете изменить отображение и порядок столбцов для основных таблиц текущей оснастки, а именно: «Наследование групповой политики», «Начальные объекты групповой политики», «Объекты групповой политики», «Связанные объекты групповой политики» и «Фильтры WMI». Вам достаточно просто выбрать из раскрывающегося списка редактируемую таблицу, в поле «Столбцы отображаются в следующем порядке» снять флажки с наименований лишних столбцов и установить их порядок, используя кнопки «Вверх» или «Вниз». Также вы можете изменять порядок столбцов непосредственно из таблицы, меняя их местами так, как вам удобно. Для того чтобы ваши изменения были сохранены при повторном открытии оснастки, в окне параметров установите флажок «Сохранять порядок и размеры изменяемых столбцов», как показано на следующей иллюстрации:

Рис. 2. Вкладка «Столбцы» параметров оснастки

Вкладка «Отчет». Используя эту вкладку, вы можете изменить папку, которая используется по умолчанию для расположения ADM-файлов. Следует помнить, что изменения, которые проводятся на данной вкладке, будут распространяться только на устаревшие ADM-файлы, а расположение файлов ADMX, которые используются в операционных системах Windows Vista и Windows 7 останется без изменений. Если переключатель будет установлен на параметре «По умолчанию», то поиск файлов ADM изначально будет проводиться в папке Windows и в том случае, если файл не будет найден, консоль GPMC будет просматривать папку объектов групповой политики (GPO), находящуюся в папке Sysvol. Если установить переключатель на параметр «настраиваемое», то консоль GPMC изначально будет искать файлы adm в той папке, которая будет указана вами, а затем в расположениях по умолчанию. Настройки данной вкладки изображены ниже:

Рис. 3. Вкладка «Отчет» параметров оснастки

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

Рис. 4. Вкладка «Общие» параметров оснастки

Создание и редактирование объектов групповой политики


Используя оснастку «Управление групповой политикой» вы можете создавать и редактировать объекты групповой политики, а также комментарии к ним для упрощения их мониторинга, удалять объекты групповых политик и проводить поиск среди существующих объектов. Рассмотрим подробно каждое из вышеперечисленных действий:


Создание объекта групповой политики с комментарием


1. Один или несколько параметров групповой политики, который применяется к одному или нескольким пользователям или компьютерам, обеспечивая конкретную конфигурацию, называется объектом групповой политики. Для того чтобы создать новый объект групповой политики, выполните следующие действия:

2. В оснастке «Управление групповой политикой» разверните узел лес, домен, название вашего домена и выберите контейнер «Объекты групповой политики». Именно в этом контейнере будут храниться все объекты групповой политики, которые вы будете создавать;
Щелкните правой кнопкой мыши на данном контейнере и из контекстного меню выберите команду «Создать», как изображено ниже:

Рис. 5. Создание объекта групповой политики

3. В диалоговом окне «Новый объект групповой политики» введите название объекта в поле «Имя», например, «Корпоративные требования» и нажмите на кнопку «ОК».

Рис. 6. Диалоговое окно «Новый объект групповой политики»

Редактирование объекта групповой политики


После того как объект групповой политики будет создан, для того чтобы настроить определенную конфигурацию данного объекта, вам нужно указать параметры групповой политики при помощи оснастки «Редактор управления групповыми политиками». Допустим, нужно отключить Windows Media Center, средство звукозаписи, а также ссылку «Игры» в меню «Пуск». Для этого выполните следующие действия:

1. Выберите созданный ранее объект групповой политики, нажмите на нем правой кнопкой мыши и из контекстного меню выберите команду «Изменить»;

2. Разверните узел Конфигурация пользователя/Политики/Административные шаблоны/Компоненты Windows/Windows Media Center;

3. Откройте свойства параметра политики «Не запускать Windows Media Center» и установите переключатель на опцию «Включить». В поле комментарий введите свой комментарий, например, «В связи с корпоративными требованиями не разрешается данным пользователям использовать текущее приложение» и нажмите на кнопку «ОК».

Рис. 7. Изменение групповых политик для созданного объекта

4. Повторите аналогичные действия для параметров политик «Запретить выполнение программы «Звукозапись»» и «Удалить ссылку «Игры» из меню «Пуск»» из узла Конфигурация пользователя/Политики/Административные шаблоны/Меню «Пуск» и панель задач.

5. Закройте редактор управления групповыми политиками.

Также, если вы создаете много объектов групповых политик, для вас окажется удобной возможность добавления комментариев к самим объектам групповых политик. Для добавления комментария к GPO, выполните следующие действия:
1. Выберите созданный ранее объект групповой политики, нажмите на нем правой кнопкой мыши и из контекстного меню выберите команду «Изменить»;

2. В дереве консоли оснастки «Редактор управления групповыми политиками» нажмите правой кнопкой мыши на корневом узле и из контекстного меню выберите команду «Свойства»;

3. В диалоговом окне «Свойства: имя объекта групповой политики» перейдите на вкладку «Комментарий» и введите примечание для вашего GPO, например, «Этот объект групповой политики запрещает указанным пользователям использовать мультимедийные приложения, а также игры в организации»;

Рис. 8. Добавление комментария для объекта групповой политики

4. Нажмите на кнопку «ОК», а затем закройте оснастку «Редактор управления групповыми политиками».

Поиск объектов групповой политики


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

1. В дереве консоли оснастки «Управление групповой политикой» щелкните правой кнопкой мыши на вашем лесу (или если вы знаете, в каком домене нужно провести поиск объекта, то можете вызвать контекстное меню для конкретного домена) и из контекстного меню выберите команду «Найти»;

2. В диалоговом окне «Поиск объектов групповой политики» в раскрывающемся списке «Искать объекты групповой политики в домене:» можете выбрать домен, для которого будет производиться поиск или оставить значение, используемое по умолчанию;

Рис. 10. Выбор домена для поиска GP

3. В раскрывающемся списке «Элемент поиска», выберите тип объекта, для которого будет выполняться поиск. В этом случае нужно выбрать элемент «Имя объекта групповой политики»;

4. Раскрывающийся список «Условие» позволяет выбрать условие для поиска. Доступные варианты «Содержит», «Не содержит» и «совпадает». При выборе условия «совпадает» вам нужно ввести точное название политики. В противном случае поиск закончится ошибкой;

5. В поле «Значение» введите значение, которое будет использовано для фильтрации поиска. Если результаты предыдущего поиска были сохранены, то значение можно будет выбрать из раскрывающегося списка;
6. Нажмите на кнопку «Добавить» для выбора условия поиска;
7. По нажатию на кнопку «Найти» будут выведены все результаты, согласно условиям поиска. Результат изображен на следующей иллюстрации:

Рис. 11. Результаты поиска

8. Для того чтобы сразу перейти к оснастке «Редактор управления групповыми политиками» нажмите на кнопку «Изменить», для сохранения текущих результатов поиска нажмите на кнопку «Сохранить результаты» (результаты будут сохранены в указанной вами папке с расширением *.csv). По нажатию на кнопку «Очистить» результаты поиска будут очищены без сохранения, а для закрытия данного диалога нажмите на кнопку «Закрыть» или на клавишу Esc.

Удаление объекта групповой политики


При работе с объектами групповых политик вам когда-то понадобится удалить существующий объект GPO. Для этого выберите объект групповой политики и выполните одно из следующих действий:
Нажмите на клавишу Delete и в диалоговом окне «Управление групповой политикой» нажмите на кнопку «Да»;
Нажмите на кнопку «Удалить» (в виде красного креста) на панели инструментов, а затем в диалоговом окне «Управление групповой политикой» нажмите на кнопку «Да»;
Нажмите правой кнопкой мыши на объекте групповой политики и из контекстного меню выберите команду «Удалить». Затем в диалоговом окне «Управление групповой политикой» нажмите на кнопку «Да».


Заключение


В этой статье рассмотрены базовые принципы работы с оснасткой «Управление групповой политикой», предназначенной для создания и управления объектов групповых политик в домене Active Directory. Вы узнали о способах открытия данной оснастки и настройки пользовательского интерфейса, а также о том, как можно создавать и редактировать новые объекты групповых политик и их комментарии, выполнять поиск существующих объектов, а также о способах их удаления. В следующей статье я продолжу описание управления инфраструктурными единицами организации, используя оснастку «Управление групповой политикой».


источник (очень зачетнгый сайт)

Настройка простейшего сервера для скачивания файлов на базе IIS 7.0 Windows Server 2008 R2

Windows Server 2008 имеет в комплекте сильно изменённую роль веб-сервера IIS. Изменения коснулись как самого веб-сервера, так и инструментов его управления. В этой заметке я коснусь только простейших настроек. Впрочем и решённую задачу назвать сложной проблематично. Итак, имеется сервер, на базе его надо настроить ftp-сервер с доступом по паролю к определённой папке и http-сервер с анонимным доступом к этой же папке, но без возможности просмотра содержимого папки.

Для начала рассмотрим процесс установки IIS. Роль веб-сервера доступна в списке стандартных ролей Windows Server 2008. И для её установки достаточно эту роль добавить.

В связи с требованиями задачи список компонентов устанавливаемых по умолчанию надо подкорректировать. Directory Browsing и Basic Authentication нам не понадобятся.

По завершении мастера установки можно проверить корректность работы сервера подключившись в браузере к http://localhost. В случае успешной установки должен отобразиться следующий сайт:

После установки FTP вернёмся к конфигурированию нашего веб-сервера. Консоль управления IIS очень сильно изменилась по сравнению с шестой версией и выглядит следующим образом:

В Authentication проверяем что к нашему веб-сайту доступ имеют только анонимные пользователи. В IIS 7.0 доступ к ресурсам сервера анонимных пользователей идёт от имени служебной учётной записи IUSR.

Далее в Basic Settings указываем папку, где будет находиться содержимое нашего сайта

и права доступа к файловым ресурсам (пользователю IUSR даём только право Read на нашу папку).

Теперь попробуем посмотреть в браузере что у нас получилось. При попытке доступа к localhost по http-протоколу получаем чистый экран

Если же будем обращаться к конкретному файлу - то сервер даст его скачать

Вернёмся к конфигурированию нашего веб-сервера. Займёмся настройками FTP. Для этого не обязательно делать отдельный ftp-сайт, можно подключить ftp к текущему нашему сайту. Делается это через команду Add FTP Publishing с консоли действий нашего IIS manager’а.

После этого в настройках нашего сайта появятся дополнительные настройки для конфигурирования FTP-сервера.

Для начала в FTP Authentication проверяем, что анонимный доступ к ftp-серверу отключен, включена только Basic аутентификация.

Далее, настраиваем FTP Authorization Rules. Предварительно создаем две локальных группы FTP Admins и FTP Users, например. Первой даём права на чтение-запись на нашем сервере, второй - только на чтени

Затем, в FTP Directory Browsing можно настроить внешний вид FTP-сайта и различные сообщения сервера.

На этом конфигурация нашего сервера заканчивается. Проверяем отсутствие доступа анонимных пользователей и доступ для пользователя - члена группы FTP Admins:

Windows 7: GodMode (режим бога)

Источник тут

Microsoft Hyper-V Server 2008 R2: строим кластер

Установка и настройка 

Одной из самых интересных новых возможностей бесплатной платформы для серверной виртуализации Microsoft Hyper-V Server 2008 R2 является возможность работать в failover-кластере. В этой статье будет рассмотрен процесс создания кластера, а так же failover и Live Migration виртуальных машин внутри него.


Некоторые из читателей наверняка слышали о появлении у Microsoft бесплатного продукта для виртуализации серверов под названием Hyper-V Server. Представляет этот продукт из себя всего-навсего до максимума урезанную ОС Microsoft Windows Server 2008. В ней доступна всего лишь одна роль: Hyper-V, и отсутствует графический интерфейс – как в режиме установки Server Core. Управлять им можно через встроенную утилиту sconfig, через командную строку и удаленно через MMC. Недавно вышла новая версия этого замечательного продукта: Microsoft Windows Server 2008 R2. Что же в ней нового?

Во-первых, Hyper-V Server 2008 R2 поддерживает уже 8 процессоров и до 2Тб оперативной памяти, тогда как предыдущая версия поддерживала только до 4 процессоров и до 32Гб памяти. Во-вторых, новая версия поддерживает работу в составе Failover-кластера, и, соответственно – все вытекающие из этого возможности R2: Cluster Shared Volumes и Live Migration. Так же поддерживаются и другие новые возможности платформы R2, как VMQ, Core Parking и т.д. В-третьих – утилита конфигурации sconfig была во многом доработана, и теперь благодаря ней можно сделать все первоначальные настройки, такие, как сетевые настройки, ввод в домен, включение удаленного управления – прямо в sconfig, без использования командной строки.

С точки зрения лицензирования имеются следующие отличия: во-первых, сам Hyper-V Server, как уже было сказано – абсолютно бесплатен. Это значит, что не придется покупать никаких лицензий ни на сам сервер, ни клиентских лицензий для него, а так же не придется платить за какие-либо дополнительные штатные возможности, как, например, у VMWare.

Тем не менее, здесь у Windows Server есть одно важное преимущество: при покупке Windows Server 2008 предоставляется право бесплатного запуска (без покупки серверной лицензии) определенного числа гостевых ОС Windows Server в пределах одного физического хоста: одной – для версии Standard, до четырех – для Enterprisre и не ограниченное число гостевых Windows Server в версии Datacenter. В случае же с Hyper-V Server таких прав не предоставляется, и каждая гостевая ОС должна иметь лицензию. Поэтому Hyper-V Server совсем не обязательно может стать самым выгодным решением. К примеру, при миграции уже существующей инфраструктуры, когда на все серверные ОС уже куплены лицензии – бесплатный Hyper-V Server будет очень даже выгодным решением. Если же планируется развертывание инфраструктуры «с нуля» — то может оказаться выгоднее купить Windows Server 2008 EE или даже Datacenter в случае, если виртуальных машин будет достаточно много.

Системные требования для Hyper-V Server такие же, как и для Windows Server 2008 с поддержкой Hyper-V. Первое, о чем необходимо помнить – процессор должен быть 64-битной архитектуры, а так же поддерживать технологию аппаратной виртуализации (Intel VT или AMD-V) и аппаратную же Data Execution Prevention (у Intel это называется Execute Disable, XD-bit, а у AMD – No-Execute, NX-bit). Так же необходимо помнить, что обе эти возможности должны быть включены в BIOS Setup, в этом нужно убедиться перед установкой ОС. Если планируется работа в кластере – процессоры на всех узлах желательно должны быть одной модели. Или хотя бы одного производителя, в противном случае перенос виртуальных машин между узлами будет невозможен. Что касается оперативной памяти – тут все считается по достаточно простой формуле: суммарный объем памяти всех виртуальных машин, которые планируется запускать плюс 1 Гбайт для самой ОС. Если же планируем использование кластеров – то надо предусмотреть запас по объему памяти для запуска виртуальных машин, которые, возможно, будут перемещаться с одного узла на другой. Для работы Hyper-V Server 2008 R2 достаточно 8Gb свободного дискового пространства, поддерживается так же запуск с флэш-накопителей. Разумеется, понадобится некий объем дискового пространства для хранения файлов виртуальных машин. Если же планируется работа в кластере – то не обойтись без внешней системы хранения данных, работающей по протоколам FC, SAS или хотя бы iSCSI.

Официально поддерживаются в качестве гостевых следующие ОС:

· Разумеется – вся линейка ОС от Microsoft: от Windows 2000 Server до Windows Server 2008 R2, и от Windows XP до Windows 7

· Novell SUSE Linux Enterprise Server версий 10 и 11 с SP1/SP2

· Red Hat Enterprise Linux 5.2 и 5.3 с одним допущением: не будут поддерживаться компоненты интеграции, и соответственно – синтетические устройства, к примеру – улучшенная поддержка мыши или виртуальный Ethernet-адаптер 10Gbit.

Все остальные ОС, вполне возможно, что и запустятся в виртуальной среде, но только на ваш собственный страх и риск: официально со стороны Microsoft поддержки не будет. Если кому-нибудь удастся запустить на Hyper-V, к примеру, FreeBSD или Solaris – буду рад, если поделитесь опытом J

Статью можно разделить на три главы. В первой главе под названием «Прежде, чем двинуться дальше…» идет сухая теория: что такое «кластер» и с чем его едят, что есть Quick и Live Migration, что такое Cluster Shared Volumes. Если вы уже знаете все это – то можете переходить сразу ко второй главе – «От теории – к практике». И наконец, в третьей главе «Проверим» — описано, как сделать Live Migration и как происходит Failover запущенных виртуальных машин на другой узел.
Прежде, чем двинуться дальше…
…давайте вспомним, что же такое «кластер»

В терминологии Microsoft различают три вида кластеров: отказоустойчивый – failover, кластер балансировки сетевой нагрузки – NLB-cluster и кластер для высокопроизводительных вычислений – high-performance cluster, он же HPC. В настоящей статье речь будет идти об отказоустойчивых кластерах.

Для чего нужен отказоустойчивый кластер? Как ясно из названия – для повышения отказоустойчивости бизнес-критичных приложений. Например – базы данных. Или, в нашем случае – целой виртуальной машины. При использовании технологий отказоустойчивой кластеризации выход из строя одного физического сервера не приведет к отказу критичного приложения: приложение будет мгновенно, или же с небольшим простоем (до нескольких минут) перезапущено на другом сервере. Тем не менее, использование такой технологии приводит к сильному удорожанию системы: во-первых – из-за необходимости использовать два и более сервера там, где хватило бы и одного, во-вторых – из-за того, что для работы кластера необходима внешняя система хранения данных, которую придется приобрести, если таковых еще нет, и в-третьих – вполне возможно, что для использования технологий кластеризации придется приобрести более дорогие версии ПО (к Hyper-V Server не относится .

Итак, отказоустойчивый кластер состоит как минимум из двух серверов, которые именуются узлами кластера (nodes). Узлы кластера периодически обмениваются между собой особыми пакетами информации, именуемыми heartbeat. Если один из узлов выходит из строя – он перестает отсылать сигналы heartbeat, и кластер отмечает узел как «сбойный». При этом, если на сбойном узле были запущены критичные сервисы – то произойдет их автоматический перезапуск на одном из работающих узлов. В зависимости от сервиса, это может произойти вообще без простоя или же с минимальным простоем в несколько минут – что все равно лучше, чем тратить несколько часов на восстановление сервера.

Все узлы кластера используют общую систему хранения данных, на которой хранятся общие данные, необходимые для работы самого кластера (так называемый «кворум») и данные, необходимые для функционирования критичных сервисов (файлы БД, виртуальных машин, и т.д.). Хотя фактически кластер состоит из нескольких физических серверов – в сети он представляется как один виртуальный сервер, имеющий свое собственное сетевое имя и IP-адрес. Обращение к кластеризованному сервису производится с использованием собственного имени и IP-адреса кластера, и до тех пор, пока кластер функционирует – к сервисам можно обращаться по одному и тому же имени, вне зависимости от того, на каком из физических серверов запущены сервисы в данный момент времени.

Как уже было сказано – технологии кластеризации должны поддерживаться на уровне ПО: как самой ОС (Windows Server 2008 Enterprise / Datacenter, Hyper-V Server 2008 R2), так и на уровне прикладного ПО (например – Microsoft SQL Server).
Таки где же профит?

Что же даст использование отказоустойчивых кластеров при виртуализации? Разумеется, это повысит отказоустойчивость виртуальных машин: в случае выхода из строя одного из серверов все запущенные на нем виртуальные машины автоматически перезапустятся на другом узле, для гостевых ОС это будет выглядеть как некорректная перезагрузка. То есть 100%-й защиты от сбоев кластер не даст, простой в несколько минут все же произойдет, и несохраненные данные, если таковые имелись – будут потеряны, но все же это значительно быстрее, чем замена неисправного сервера с переносом виртуальных машин.
Quick and Live Migration

Кроме этого, использование отказоустойчивой кластеризации позволит переносить виртуальные машины с одного сервера на другой намного быстрее за счет технологий Quick Migration и Live Migration.

Технология Quick Migration работает следующим образом:

1. Перемещаемая виртуальная машина переводится в состояние Save State.

2. На сервере, куда планируется перемещать виртуальную машину – создается новая виртуальная машина с таким же именем и с такой же конфигурацией.

3. К созданной виртуальной машине монтируются все необходимые виртуальные диски.

4. Старая виртуальная машина удаляется.

5. Новая виртуальная машина запускается с восстановлением из Save State.

Этот способ перемещения имеет один серьезный недостаток: процесс перехода виртуальной машины в Save State и последующее восстановление занимает определенное время, в течение которого виртуальная машина остается недоступной. И, к примеру, если к ней подключались пользователи по RDP – произойдет обрыв сессии, что в принципе неприятно, но и не смертельно.

В Windows Server 2008 R2 появился новый способ перемещения под названием Live Migration. Происходит это следующим образом:

1. На сервере, куда планируется перемещать виртуальную машину – создается новая виртуальная машина с таким же именем и с такой же конфигурацией

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

3. Как только содержимое памяти на обеих виртуальных машинах будет полностью совпадать – происходит перемонтирование всех виртуальных дисков к новой виртуальной машине.

4. Новая виртуальная машина теперь работает, а старая – удаляется.

Поскольку при Live Migration содержимое памяти копируется «на лету», без останова виртуальной машины – то время простоя фактически равно нулю. Небольшой, размером в малые доли секунды, простой будет на этапе перемонтирования виртуальных дисков, но он будет незаметен для пользователя, так как TCP-сессии за этот момент не успеют оборваться по тайм-ауту. Тем не менее, здесь имеется небольшой нюанс: копирование содержимого памяти осуществляется по сети, и длительность процесса зависит от нагруженности сети. Поэтому, если сеть достаточно сильно загружена – рекомендуется добавить на серверах дополнительные сетевые интерфейсы и создать отдельную сеть исключительно для трафика при миграции. Так же надо помнить, что существует ограничение в 10 циклов при копировании содержимого памяти. То есть, если содержимое памяти очень часто и очень сильно меняется (к примеру – база данных с очень большим количеством транзакций в секунду), и/или из-за загруженности сети копирование происходит достаточно медленно – миграция может не произойти вообще.
Cluster Shared Volumes

Прежде, чем перейти к практике – нужно сказать еще об одной новой возможности в Windows Server 2008 R2: кластерной файловой системе, Cluster Shared Volumes (CSV).

Без использования кластерных ФС два узла кластера не могут обращаться одновременно к одному и тому же дисковому устройству: при обращении к нему с одного из серверов на другом устройство переходит в состояние Offline. Поэтому до появления CSV было очень сложно запускать одновременно несколько виртуальных машин на разных узлах кластера: для этого приходилось для каждой виртуальной машины создавать свой отдельный LUN, что создавало дополнительные сложности. С использованием же CSV эта проблема решается: CSV позволяет осуществлять одновременный доступ к данным на одном дисковом устройстве с нескольких серверов.

Тома CSV не имеют в системе своих букв. Вместо этого, они на манер UNIX-like монтируются как папки в системном разделе. При использовании CSV на системном диске (как правило, это диск C: ) создается папка ClusterStorage, и все дисковые устройства, используемые как CSV, монтируются в ней как подпапки в виде C:\ClusterStorage\volume1, C:\ClusterStorage\volume2, …, C:\ClusterStorage\volumeN. В связи с этим необходимо учитывать, что на всех узлах кластера системный раздел должен иметь одинаковую букву. Так же необходимо учитывать, что CSV в настоящий момент официально поддерживаются только в качестве хранилища данных для виртуальных машин Hyper-V.
От теории – к практике

Вы все еще не устали читать? Поздравляю. Теперь мы посмотрим, как это все работает на «реальном железе».

Итак, для демонстрации работы кластера на Hyper-V Server 2008 R2 была создана тестовая инфраструктура, состоящая из трех физических машин:

· Node1 – будет использоваться в качестве первого узла кластера

· Node2 – будет использоваться в качестве второго узла кластера

· Server – хост для запуска виртуальной машины DC

Как нетрудно догадаться, на Node1 и Node2 установлен Hyper-V Server 2008 R2, а на Server – Windows Server 2008 R2 с ролью Hyper-V. Виртуальная машина DC, запущенная на Server, используется во-первых – в качестве контроллера домена TEST.LOCAL, а во-вторых – в качестве системы хранения данных. Для этого на ней установлено ПО Starwind iSCSI Target в бесплатной версии. Бесплатная версия позволяет создавать iSCSI targets объемом до 2Tb, но надо помнить, что использовать в продакшене ее нельзя. Для нашей демонстрации было создано два виртуальных дисковых устройства: объемом 0,5Gb и 20Gb, впоследствии подключенные к Node1 и Node2 с использованием iSCSI. Устройство меньшего объема будет использоваться в качестве кворумного ресурса для работы кластера, а большего – для хранения данных виртуальных машин.

Все сервера объединены сетью Gigabit Ethernet, Node1 и Node2 являются членами домена TEST.LOCAL.

Схема нашей тестовой инфраструктуры выглядит следующим образом:

Установка

 Начнем с установки.  УСТАНАВЛИВАЙТЕ АНГЛИЙСКУЮ ВЕРСИЮ!!!!!
Установка с компакт-диска не представляет собой ничего сложного — загрузились с диска, выбрали язык, согласились с лицензионным соглашением, выбрали раздел и «ушли курить» минут на 10.  (Лучше конечно сделать загрузочную флешку)

После установки появятся два окошечка синее для настроек и обычное cmd

1) Для начала закинем компьютер в домен и присвоем ему имя. (ребут)
2)  Потом я бы посоветовал его обновить.
3) Переходим в 4 меню настройки удаленного управления  включаем там mmc powershell и  удаленное управление.
4) Переходим в 7 пункт меню и включаем RDP.
5) 11 меню включаем кластер.
ребут.

Для управления сервером вам потребуется скачать и установить Remote Server Administration Tools (RSAT) для клиентской операционной системы и установить компонент Диспетчер Hyper-V, или добавить роль Hyper-V и установить компонент Диспетчер Hyper-V на Windows Server 2008 R2.
Пытаемся подключиться к нашему серверу и видим ошибку, которая говорит нам занести админу пива, чтобы он выдал нужные права. Вспомнив, что мы и есть тот самый админ, не падаем духом и читаем дальше.
John Howard, который занимает пост Senior Program Manager in the Hyper-V team at Microsoft, написал цикл статей, посвященный раздаче необходимых прав, а в последствии состряпал замечательную утилиту HVRemote, которая произведет хитроумную настройку сервера и клиента, не взрывая мозг админу.
Ей мы и воспользуемся. Итак, скачиваем, заходим на сервер по \\server\C$, кладем HVremote.wsf в папку Windows (или в любое другое место, но тогда не забываем указывать полный путь до нее). Запускаем на сервере:
cscript hvremote.wsf /add:domain\account ***, где domain\account – ваше имя пользователя в домене. Скрипт пропишет все необходимые привилегии, в том числе откроет нужные порты на фаерволе.
Затем, на клиенте cscript hvremote.wsf /mmc:enable, скрипт создаст исключения фаервола.
Теперь можно запускать Диспетчер Hyper-V и подключаться к нашему серверу, создавать виртуалки и радоваться жизни.

Еще после установки RSAT если не получается подключиться с клиентского компа к службе управления виртуальными дисками, нужно проверить в брандмауэре включены ли две службы

Настраиваем второй компьютер аналогично.


Потом на DC устанавливаем StarWind.

Теперь нужно настроить ISCSI. Устанавливаем Starwind либо Windowый.

Покажу пример на Starwind

Нужно создать кворум гигов 5 и стораж гогов 40 либо меньше либо больше.

Теперь нам осталось подключить iSCSI-диски. Кто-то спрашивал, зачем в режиме Server Core нужна мышка? Переходим в командную строку и запускаем Microsoft iSCSI Initiator командой iscsicpl. Соглашаемся с запуском сервиса iSCSI и видим окно инициатора:

Добавляем наш DC в Discovery Portal. Для этого на закладке Discovery нажимаем кнопку, как не трудно догадаться, Discovery Portal, и вбиваем сетевое имя нашего iSCSI-сервера, в нашем случае – DC.

Сразу после этого на закладке Targets должны появиться iSCSI-устройства, доступные на сервере. В нашем случае их будет целых два:

Их необходимо подключить кнопкой Connect, а затем перейти на закладку Volumes and Devices и выбрать Auto Configure.

Вроде как все. Но не совсем. Дело в том, что дальше нам придется подключаться к узлу через консоль MMC, но нас будет ждать облом? Кто угадает почему – может взять с полочки пирожок.

Все дело в том, что когда мы создавали виртуальную сеть – был создан новый сетевой адаптер, и на него были перенесены все сетевые настройки. Включая и настройки фаерволла. Поэтому нам необходимо повторить ( в меню sconfig пункт 4, затем 1 и 3).

Вот теперь все. Можно разлогиниться.

Мы находимся в интерфейсе виртуальной машины DC. Открываем консоль Server Manager, подключаемся к Node1 и идем Storage – Disk Management. Нам тут же предлагают проинициализировать наши два новых диска, что мы и делаем. После инициализации на каждом из дисков создаем раздел объемом на весь диск и форматируем. Файловая система, разумеется, NTFS. Размер кластера я для тестовой среды оставил дефолтным. 0,5Gb-диску я присвоил букву Q: и метку Quorum, а другому, соответственно – S: и Storage. Хотя это и не существенно, можно выбирать любые. После форматирования выглядело все вот так:

Теперь можно и нужно подготовить второй узел: заходим на Node2, устанавливаем компоненту Failover Clustering, подключаем iSCSI-диски и включаем удаленное управление еще раз – по аналогии с действиями на Node1.

Проверяем Server Manager’ом подключение iSCSI-дисков на Node2. Диски подключились, правда буквы им были выданы другие – D: и F:. Можно для проформы поменять их на Q: и S:, можно этого и не делать.
Собираем кластер

Наконец-то мы добрались собственно до сборки кластера. Все операции с кластером будут осуществляться через консоль Failover Cluster Managemer (далее – FCM).

Итак, мы открыли FCM. Первое, что нам необходимо сделать – это проверить, «взлетит или не взлетит», то есть соберется ли кластер из наших узлов или нет. Для этого используется мастер

Все, что здесь необходимо сделать – это выбрать сервера, которые будут входить в кластер, и выбрать тесты из списка. Тестов много, и я рекомендую провести их все – потому что только в случае успешного прохождения всех тестов решение будет поддерживаемым. Если все прошло успешно – то будет примерно такая картинка (Testing has completed successfully):

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

Вы все еще не уснули? Тогда переходим непосредственно к сборке кластера. Запускаем мастер сборки (Create a Cluster). Мастер этот похож на предыдущий, так же будет необходимо выбрать наши узлы Node1 и Node2, а затем – задать сетевое имя и IP-адрес для самого кластера:

После окончания процесса сборки наш кластер появится в дереве FCM:

Разных опций и настроек у нас много. Вначале нужно посмотреть на раздел Nodes, проверить, что оба узла в состоянии Up (работают), а в разделе Storage – убедиться, что диск Q: назначен кворумом, а 20Gb-диск появился в Available Storage:

Создаем CSV

Теперь попробуем создать Cluster Shared Volume, на котором будем хранить наши виртуальные машины. Для этого заходим в корень консоли FCM и выбираем Enable Cluster Shared Volumes. Нас предупредят, что CSV разрешается использовать только для хранения файлов виртуальных машин Hyper-V, все остальное – unsupported solution:

После согласия с этим предупреждением в дереве настроек нашего кластера появится новый раздел с названием… ни за что не угадаете… Cluster Shared Volumes! Заходим туда и добавляем (Add Storage) наш диск S: объемом 20Gb в CSV:

Создаем виртуальную машину как сервис кластера

Кластер готов, теперь можно перейти к экспериментам. Для этого создадим виртуальную машину. Это можно сделать через оснастку Hyper-V Manager, но проще сделать через FCM – тем более, что туда все равно придется вернуться, чтобы сделать нашу виртуальную машину ресурсом кластера. В разделе Services and applications есть опция Virtual Machines, через которую мы и создаем нашу тестовую виртуальную машину, например, на узле Node1:

Запускается стандартный мастер создания виртуальной машины, такой же, как и в Hyper-V Manager. Мы будем хранить наши виртуальные машины на CSV, и поэтому надо указать соответствующий путь (C:\ClusterStorage\volume1):

В остальном – все полностью аналогично созданию виртуальной машины в Hyper-V Manager. Отмечу лишь, что назвали мы нашу машину TestVM, дали ей 512Mb памяти и диск фиксированного объема 15Gb.

Запускаем виртуальную машину, устанавливаем ОС. Отсюда же, из FCM, подключаемся к ее консоли (Connect to virtual machines) и проходим процесс установки ОС и ее настройки (сетевые настройки, ввод в домен, etc.)

Проверим?

Давайте теперь проверим, как работает Live Migration. Для этого на нашей тестовой виртуальной машине создадим расшаренную папку и начнем копировать в нее некий файл большого объема (к примеру – тот самый ISO-образ, с которого была установлена ОС). В процессе копирования переместим виртуальную машину с узла Node1 на Node2 с помощью Live Migration:

Как мы видим – процесс миграции занимает несколько секунд, а копирование файла при этом не прерывается.

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

Таким образом, полной отказоустойчивости использование Failover Clustering обеспечить не может, но тем не менее failover в течение нескольких минут – это все же лучше, чем ручная замена сервера и перенос виртуальных машин в течение нескольких часов.

Удаление и проблемы.

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

Принудительное исключение узла из отказоустойчивого кластера Windows Server 2003 с помощью средства Cluster.exe

Остановите службу кластеров, выполнив следующую команду:
net stop clussvc


После остановки службы кластеров принудительно исключите узел, выполнив следующую команду:

Cluster <ClusterName> node <NodeName> /force

В моем случае  cluster.exe cluster node cluster4 /force

Заключение

Как мы убедились в этой статье, Hyper-V Server 2008 R2 вполне подходит для промышленного применения: он поддерживает все возможности Hyper-V R2 и может работать в составе отказоустойчивого кластера. Здесь мы на практике ознакомились с процессом развертывания failover-кластера на базе Hyper-V Server и проверили работу Live Migration и Failover. На вопрос что же лучше использовать в качестве среды для виртуализации – Windows Server или Hyper-V Server – однозначный ответ дать невозможно. Windows Server поддерживает работу в составе кластера только в версиях Enterprise и Datacenter, которые стоят не дешево, зато они дают право на бесплатное использование определенного числа гостевых ОС. Hyper-V Server сам по себе бесплатен, но все гостевые ОС должны иметь лицензии. Разумеется, речь идет только об ОС Microsoft. Из этого следует, что Hyper-V Server больше всего подходит для виртуализации уже действующей структуры, когда все лицензии уже куплены. Если же планируется развертывание инфраструктуры «с нуля», то Windows Server EE/DC может оказаться предпочтительнее по суммарной стоимости лицензий. Сравнивать с решениями VMWare я не возьмусь, поскольку плохо разбираюсь в их лицензировании. Тем не менее, бесплатный Hyper-V Server не требует покупки дополнительных лицензий на каждую фичу типа Live Migration или бэкапа виртуальных машин «на лету».

На этом хотелось бы закончить – статья и так получилась слишком большой, свое мнение просьба высказывать в комментариях. Спасибо за внимание!




ССЫЛКИ НА ДИСТРИБЫ.
Microsoft® Hyper-V™ Server 2008 R2 
StarWind Free iSCSI Target Software 
Microsoft iSCSI Software Target 3.3 (если кому приглянется) 
Microsoft iSCSI Software Initiator Version 2.08 
Hyper-V Remote Management Configuration Utility