Russian Windows Virtualization Discussion

Лицензирование виртуальных машин. Часть 8. Новый VECD — Virtual Enterprise Centralised Desktop

В мае прошлого года я рассказывал вам о VECD (тогда еще Vista Enterprise Centralised Desktop) и о правилах лицензирования VECD и VECD для Software Assurance. Сейчас, с выходом Windows 7 и с появлением специальных наборов лицензий VDI Suite, сам VECD несколько изменился, попутно переименовавшись в Virtual Enterprise Centralised Desktop.

Существует две различных лицензии VECD, которые покрывают сценарий доступа к экземплярам клиентских ОС, запущенных в виртуальных машинах, выполняющихся на серверах. VECD разрешает доступ к таким экземплярам с персональных компьютеров, лицензированных для использования Windows 7 Professional, Enterprise или Ultimate с текущей Software Assurance, с тонких клиентов, не имеющих лицензии Windows, или с клиентов с Windows, не имеющих Software Assurance. Более того, VECD может покрывать и компьютеры, не принадлежащие вам, если с них вы обращаетесь к вашей сети.

VECD и VECD для SA лицензируются на устройство на основании ежемесячной подписки без права владения. Переведя эту юридическую терминологию на человеческий язык мы понимаем, что VECD следует привязывать к устройствам (а не пользователям) и что VECD — это всегда подписка (аренда ПО) без права выкупа. Права на VECD заканчиваются вместе с отказом от продления подписки или с разрывом соглашения, в рамках которого она была приобретена.

• Для каждого компьютера, имеющего лицензию Windows с действующей Software Assurance (вне зависимости от того, какая ОС в действительности установлена на этом ПК), действует предложение VECD для Software Assurance.
• Для тонких клиентов, компьютеров без SA или компьютеров, не принадлежащих вашей организации, действует предложение VECD.

Права на установку VECD дают вам возможность установить и хранить неограниченное число копий клиентской ОС на серверах и дисковых хранилищах. При этом в любой момент времени разрешается выполнять не более четырех экземпляров в виртуальных машинах (программно-эмулируемых аппаратных ресурсах) и осуществлять доступ к этим экземплярам с лицензированного устройства. Несмотря на права, разрешающие одновременное использование до четырех экземпляров, лицензия VECD жестко ограничивает использование всех четырех экземпляров одним пользователем в один момент времени.

Варианты лицензирования и доступность для заказа

VECD для Software Assurance — это лицензия Windows 7 Enterprise для заказчиков, которым нужен VECD для персональных компьютеров, покрытых действием Software Assurance для Windows Client. Т.е. действующая лицензия на Windows Client и текущая Software Assurance являются обязательным условием применимости VECD для SA к компьютеру.

VECD — это лицензия, доступная для бездисковых тонких клиентов, для компьютеров без действующей Software Assurance (в том числе — для ПК под управлением ОС производства не Microsoft) или для компьютеров, принадлежащих сторонним организациям, имеющим доступ к вашей сети. По сути, это лицензия Windows 7 Enterprise для заказчиков, использующих или собирающихся использовать тонкие клиенты как основные устройства для доступа к виртуальным экземплярам клиентских ОС, но не имеющих действующей Software Assurance для этих тонких клиентов.

Издания. В рамках VECD или VECD для SA на условиях, описанных выше, вы имеете право использовать Windows 7 Enterprise, Professional или Ultimate, а также Windows Vista Business, Enterprise или Ultimate, равно как и корпоративные издания предыдущих версий ОС Microsoft.

Доступность в программах лицензирования. Варианты VECD доступны в программах лицензирования Select, Enterprise, Open Value, School and Campus. (School and Campus не действует на территории России).

Стоимость. Точную стоимость следует уточнить у вашего поставщика. Примерно скажу, что VECD для SA стоит порядка 23$ в год, а VECD — порядка 110$ за устройство в год.

Одним из часто задаваемых вопросов является возможность использования розничных (FPP) версий клиентских ОС в виртуальных машинах на сервере для задач VDI. Короткий ответ — да, лицензия это позволяет, но... Взглянем на таблицу, что же нам дает VECD в сравнении с FPP.

Примечания

• VECD для SA доступна только для устройств, принадлежащих вашей организации.
• В случае непродления Software Assurance или разрыва соглашения заканчиваются все права на VECD и права на четыре одновременно запущенных экземпляра.
• Лицензии OEM не могут быть использованы для сценариев VDI (в отличие от FPP), так как они жестко привязаны к оборудованию и не включают прав доступа по сети.
• Software Assurance и VECD позволяют вам дополнительно приобрести MDOP для конечного устройства.
• Права на MDOP включены в лицензию VDI Suite, так что если вы используете комбинацию VECD + VDI Suite, то для использования MDOP вам не требуется покупка отдельной лицензии.
• Если ОС использует службы Windows Server — например, DHCP, DNS или Active Directory — то, помимо всего вышеописанного, потребуется и приобретение Windows Server CAL.

Лицензирование виртуальных машин. Часть 7. VDI Suite — кардинальные изменения лицензирования VDI

Полтора года назад мы уже рассматривали сценарии лицензирования VECD. Многое с тех пор изменилось, сам VECD теперь уже не тот, о чем будет рассказано на днях, — но главным изменением стало внятное комплексное лицензирование сценариев VDI. Ведь очевидно, что кроме самой ОС, «где-то» запускаемой, к данной ОС должен подключаться пользователь (например, по RDP — для чего тоже нужна соответствующая лицензия). Более того, для серверов виртуализации потребуется мониторинг и управление обновлениями, а также централизованное управление виртуальными машинами. Кроме того, всё это потребуется и клиентскими ОС — включая доставку приложений, поддержание их в актуальном состоянии, а также учёт. Ну и, наконец, потребуется и какое-то решение по динамической доставке ПО до клиента.

В результате разобраться, какой же набор лицензий, схем и программ лицензирования потребуется для реализации сценария VDI на платформе Microsoft, было крайне тяжело. Но теперь, с первого октября, в прайс-листах появился новый пункт, а точнее даже два — VDI Suite Standard и VDI Suite Premium. Оба этих набора закрывают покрывают потребности в обслуживании ОС, лицензированной по VECD, в сценарии VDI. Внимание — лицензии VDI Suite не заменяют собой лицензий VECD (т.е. лицензии на саму ОС, которая может использоваться и не в сценариях VDI), а лишь дополняют ее, что удобно в случае реализации VDI на платформе Microsoft.

В VDI Suite Standard входит минимальный набор лицензий на ПО, необходимое для построения VDI полностью на решениях Microsoft. Предполагая, что сами серверы виртуализации используют бесплатный Hyper-V Server 2008 R2 (с поддержкой Live Migration, кластеризации до 16 узлов, общей файловой системы Cluster Shared Volumes), VDI Suite Standard позволяет вам управлять этим серверами и клиентскими ОС в ВМ, лицензированных по VECD, при помощи последних версий SCVMM, OpsMgr и SCCM. Также этот набор включает права на использование RDS (Remote Desktop Services Protocol, ранее известный как RDP) для подключения к виртуальным машинам и права на использование MDOP (Microsoft Desktop Optimization Pack), в частности — клиентскую редакцию APP-V.

В VDI Sute Premium входит все вышеперечисленное плюс неограниченные права на использование RDS (т.е. полноценная терминальная лицензия, позволяющая вашим пользователям работать и с другими терминальными службами и приложениями), а также лицензия на APP-V для RDS (об APP-V, MDOP и их лицензировании отдельно от VDI я также планирую рассказать в будущем).

Обратите внимание на то, насколько просто и ясно все стало в сравнении со списком непонятных лицензий, упомянутых мной в первом абзаце, требуемых для решения этой задачи ранее.

Ориентировочная цена на VDI Suite Standard для одного пользователя на один год составляет в США 21$, VDI Suite Premium — 53$ в год. При сравнении с 250$ в год за VMware View Premier, где нет ни управления, ни мониторинга клиентских ОС (зато, будем честными, есть «экспериментальная», но от того не менее интересная возможность Offline Desktop), разница в цене в пять раз может играть существенную роль в принятии решения. Но не забудьте, что в обоих случаях, помимо Microsoft VDI Suite или VMware View, вам в любом случае обязательно потребуется лицензия VECD для самой ОС в ВМ, а также лицензии клиентского доступа Windows CAL, если эти клиентские ОС или их пользователи используют сетевые службы Windows Server — такие, как DHCP, DNS, Active Directory и так далее.

Тонкости лицензирования VDI Suite

Каждая лицензия VDI Suite включает:

1. доступ и использование ПО VDI с вашего устройства, лицензированного по VECD, устройства VDI и с других устройств, где запущены разрешенные лицензией VDI экземпляры ОС. (С виртуальных машин, запущенных на серверах виртуализации);
2. права на управление и мониторинг виртуальных экземпляров клиентских ОС на ваших серверах VDI при помощи перечисленных выше продуктов семейства System Center.

VDI Standard Suite и VDI Premium Suite предоставляют вам права на использование в течении срока действия вашего Select/Enterprise Enrollment или Open Value Agreement любых версий следующих компонентов ПО VDI:

• Windows Server Remote Desktop Services («RDS»);
• System Center Virtual Machine Manager («VMM»);
• System Center Configuration Manager («SCCM»);
• System Center Operations Manager («OpsMgr»).

При использовании VDI Suite Standard вы имеете право на доступ к Remote Desktop Services прямым или косвенным образом с вашего устройства, лицензированного для VDI, кроме случаев доступа по RDS к Windows Server для работы с его графическим интерфейсом — как с вашего VDI устройства, так и с виртуальной машины, запущенной на сервере VDI.

При доступе через RDS к клиентским ОС с вашего устройства VDI или с вашей виртуальной машины, вам не требуется отдельная RDS CAL. Однако, согласно PUR, для использования клиентскими ОС служб, представляемых Windows Server, вам потребуется иметь Windows Server CAL на оба этих устройства или на вашего пользователя.

При использовании VDI Suite Prmium вы имеете дополнительные возможности:

• Remote Desktop Services. Вы имеете права доступа к Windows Server — как с вашего устройства VDI, так и с виртуальной машины на сервере VDI. Лицензии RDS CAL для этого уже не требуется. Опять-таки, оба устройства, или пользователь при этом всё равно должны иметь Windows Server CAL, если используются службы АД, DHCP или DNS на Windows Server.
• Application Virtualization for Remote Desktop Services. Каждая лицензия VDI Suite Premium включает в себя те же права, что и лицензия APP-V for RDS. Вы можете использовать эту технологию на вашем сервере VDI и получать к ней доступ с устройств VDI, к которым вы привязали лицензию VDI Suite Premium. Вам не требуется покупать отдельную лицензию APP-V for RDS CAL для тех устройств VDI, к которым привязана VDI Suite Premium. Требование на Windows Server CAL для каждого устройства или каждого пользователя остается в силе.
• Перепривязка лицензий VDI Suite. Для VDI Premium Suite работает право, позволяющее вам перепривязать лицензию VDI Suite Premium с одного устройства VDI на другое на длительный срок (не чаще чем раз в 90 дней). Вы имеете право на перепривязку лицензии VDI Suite Premium к другому устройству и в более ранний срок, если ваше ранее лицензированное устройство VDI вышло из строя и не будет более использоваться в вашей инфраструктуре (кратковременные ремонты не позволяют делать перепривязку чаще, чем раз в 90 дней. Допускается только полный окончательный отказ от данного устройства).

Определения

• Экземпляр клиентской ОС — экземпляр клиентской (не серверной) операционной системы, в сценарии VDI запущенный в виртуальной машине.
• Устройство VDI — устройство (ПК или тонкий клиент), покрытый лицензией VECD и VDI Suite, с которого осуществляется доступ и использование к экземплярам клиентских ОС на виртуальных машинах.
• Сервер VDI — сервер, на котором запущены экземпляры клиентских ОС, к которым вы обращаетесь с устройств VDI.
• Лицензия VDI Suite — подразумевает лицензию VDI Suite Standard или VDI Suite Premium.
• ПО VDI — программное обеспечение Microsoft, права на использование которого вам предоставляются лицензией VDI Suite.

Примечания

• Вы можете привязывать лицензию VDI Suite только к устройствам. Привязка лицензий VDI Suite к пользователям невозможна.
• Лицензии VDI Suite предоставляются только по подписке с оплатой за срок использования. Постоянных лицензий, приобретаемых один раз и действующих без ограничения по времени, не существует. Права на использование ПО по подписке заканчиваются по окончанию или прекращению действия вашего соглашения, в рамках которого вы брали в аренду данное ПО.
• Вне зависимости от ОС, установленной на устройстве VDI, для осуществления доступа к экземплярам клиентских ОС Microsoft, запущенных в виртуальных машинах на серверах VDI, вам необходима лицензия VECD или VECD for Software Assurance, привязанная к устройству VDI.
• Все цены в статье приведены лишь для ориентира. Конкретные цены для вашей организации уточняйте у вашего поставщика.
• Если ваши хосты виртуализации используются для задач VDI и его сопровождения, то лицензии VDI Suite, купленные для клиентов VDI дают вам права на управление виртуальными машинами и хостом при помощи продуктов System Center. Для хостов не нужны отдельные Server Management лицензии управления. Однако, в вашей инфраструктуре должны быть SCCM/SCOM серверы, лицензируемые отдельно. SCVMM, как продукт сервера управления бесплатен.
• Если вы используете стороннюю виртуализацию и решения VDI (не от Microsoft), вам требуются следующие лицензии Microsoft: на каждое рабочее место покрытое Windows + SA - одна лицензия VECD for SA, на каждого тонкого клиента, ПК с ОС не от Microsoft, ПК с Windows без SA или ПК внешних организаций - одна лицензия VECD. Плюс - все ПК и все ВМ должны иметь Windows CAL, если они используют службы Windows Server, такие как Active Directory, DHCP, DNS, File/Print Servers, итд.

Microsoft Deployment Toolkit 2010 — инвентаризация на службе виртуализации

Все большее количество компаний используют виртуальные машины в промышленной среде. Следовательно, нужно задуматься об автоматизации установки ОС в виртуальной среде. Иметь раздельные инструменты для установки ОС на физические и виртуальные серверы выглядит накладным. Значит, универсальные средства установки должны понимать азы технологий виртуализации, различать основные сценарии и уметь оценивать аппаратные требования и возможности. Хороший тому пример — представленный недавно обновленный набор инструментов для развёртывания «Microsoft Deployment Toolkit 2010» (далее — просто «MDT 2010». Действительно, стандартный сценарий аппаратной инвентаризации «ZTIGather.wsf», выполняемый в процессе установки ОС, теперь собирает дополнительно следующую информацию:

• IsHypervisorRunning. Переменная, принимающая значение «True», если обнаружено, что идет работа поверх гипервизора (например, Hyper-V).
• SupportsVT. Переменная, принимающая значение «True», если процессор поддерживает аппаратную виртуализацию (Intel VT или AMD-V) и данная настройка включена в BIOS. Это может быть полезно не только на серверах, но и на клиентских ОС. Например, в сценарии установки Windows 7 в зависимости от возвращенного значения можно принять решение об установке Windows Virtual PC и Windows XP Mode, которые требуют поддержки аппаратной виртуализации. Очевидно, что внутри виртуальных машин, где технологии аппаратной виртуализации не работают, эта переменная всегда будет иметь значение «False».
• SupportsNX. Переменная, принимающая значение «True», если процессор и BIOS поддерживают технологию «NX» (No eXecute) или «XD» (eXecute Disable), которые необходимы для работы Hyper-V и ряда других платформ виртуализации.
• Supports64Bit. Переменная, принимающая значение «True» для процессоров с поддержкой технологий «EM64T» или «AMD64». В MDT 2008 аналогичную информацию можно было получить из переменной «CapableArchitecture».
• SupportsHyperVRole. Переменная, принимающая значение «True» в случае, когда все три предыдущих переменных («SupportsVT», «SupportsNX» и «Supports64Bit») вернули значение «True» — следовательно возможна установка роли Hyper-V.
• IsVM. Переменная, принимающая значение «True» если обнаружится, что сценарий выполняется в виртуальной машине. Технически на данный момент гарантированно определяются платформы виртуализации Hyper-V, Virtual PC, Virtual Server 2005 и VMware. Для Citrix Xen, Sun VirtualBox и более экзотических гипервизоров корректная обработка не гарантирована.
• VMPlatform. Переменная, принимающая название обнаруженной платформы виртуализации в том случае, когда на прошлом шаге «IsVM» вернула «True». Например — Hyper-V, VS2005, VMware или VirtualBox.

Как же это использовать в MDT? Вариантов несколько — от рассмотренного выше сценария установки Windows Virtual PC и Windows XP Mode на совместимых ПК во время развёртывания Windows 7 и автоматической установки роли Hyper-V на совместимых серверах до установки требуемых дополнений или служб интеграции при установке ОС в виртуальной среде. Рассмотрим это на примере Hyper-V как технологии виртуализации, наиболее близкой моим читателям.

Предположим, что в Deployment Workbench мы делаем Task Sequence для установки 32-битной версии Windows 7. Клиентские ОС не имеют встроенных служб интеграции, и в отличии от Windows Server 2008 R2 вам потребуется установить их отдельно. Рассмотрим на примере сценария Light Touch, как добавить установку служб интеграции в случае необходимости (то есть в случае, если ОС устанавливается в ВМ на платформе Hyper-V).

В Deployment Workbench нам потребуется создать приложение «Hyper-V Integration Services x86», указав путь до дистрибутива 32-битной версии. (Это каталог «%SystemRoot%\VMguest\support\x86» на сервере с установленной ролью Hyper-V). В качестве  команды установки следует указать «setup.exe /quiet /norestart». В свойствах приложения выбрать настройку «Reboot the computer after installing this application», добавить это созданное приложение в Task Sequence и указать следующее условие для установки приложения: «VMPlatform equals Hyper-V». То же самое придётся повторить и при подготовке Sequence с 64-битной версией ОС. То есть создать приложение «Hyper-V Integration Services x64», указать путь до дистрибутива 64-битных служб («%SystemRoot%\VMguest\support\amd64»), ту же команду, требование перезагрузки и условие выполнения «VMPlatform equals Hyper-V».

Для сценария Zero Touch с использованием SCCM все аналогично, только создаем не приложение, а пакет SCCM. Надеюсь, что это поможет вам оптимизировать процессы установки ОС в виртуальной и физической среде, перейдя к единому способу развёртывания.

Как обновить VMM 2008 до 2008 R2 или перейти с предварительной (RC)/ознакомительной (Evaluation) версии на полную

Уже совсем скоро, а именно — первого октября SCVMM 2008 R2 станет доступен заказчикам на сайте MVLS через программу Enterprise Agreement. А также тем, кто ранее покупал SCVMM 2008 с возможностью Software Assurance (SA) — например, в составе Server Management Suite Enterprise (SMSE) или Datacenter (SMSD). С 9 сентября, как мы недавно заметили, SCVMM 2008 R2 доступен для подписчиков MSDN/TechNet. А те, кому этот продукт был необходим раньше, могли установить 180-дневную ознакомительную (Evaluation) версию, представленную в конце августа, или же ещё с июня пользуются кандидатом для выпуска (Release Candidate).

Сегодня речь пойдет о том, как правильно обновлять ваш SCVMM 2008 до SCVMM 2008 R2, как перейти с кандидата для выпуска R2 на окончательную версию, и как перейти с 180-дневной версии продукта на коммерческую версию без ограничений срока действия. Мое изложение основывается на опыте в нескольких завершающихся проектах и официальных рекомендациях по обновлению, представленных в библиотеке TechNet.

Обновление с SCVMM 2008 до SCVMM 2008 R2

Обновление с SCVMM 2008 до SCVMM 2008 R2 происходит штатным образом через установку «поверх» (без удаления предыдущей версии). Все ваши настройки и данные при этом сохранятся.

Перед обновлением убедитесь, что в данный момент не выполняются никакие задачи (Jobs). Имейте в виду, что после обновления до версии R2 все выполненные ранее задачи останутся в истории (Job History), но не будут доступны для повторного запуска. Дело в том, что формат хранения задач в R2 изменился.

Не забудьте сделать резервную копию базы данных VMM перед обновлением. В случае возникновения каких-либо проблем в процессе обновления вы всегда сможете переустановить VMM 2008 и подключить заведомо работоспособную версию базы.

Теперь запустите процесс установки SCVMM 2008 R2 на сервере, где установлен SCVMM 2008. Если у вас включен User Account Control, то программу установки всегда требуется запускать в режиме повышенных привилегий администратора (Run as Administrator, Elevated). Установщик обнаружит на вашем сервере уже имеющуюся версию SCVMM 2008 и запустит специальный мастер обновления (Upgrade Wizard). Мастер покажет вам установленные компоненты и предложит их обновить. При этом вы можете одновременно доставить функционал, ранее не установленный на данном сервере. Например, если у вас были установлены только серверная роль SCVMM 2008 и библиотека, но отсутствовали Консоль администратора и Портал самообслуживания, вы можете в мастере обновления выбрать недостающие компоненты, — мастер сначала обновит установленные, а затем доставит новые.

После того, как вы обновили сервер и его компоненты, вам требуется из консоли администратора обновить список управляемых узлов. Для этого в дереве узлов (hosts) и в дереве библиотек (Library) требуется выполнить операцию Refresh. Если вы это не сделаете сами, компонент «VMM Host Refresher» сделает это за вас через несколько часов. При этом агенты старой версии на управляемых узлах обнаружат, что база данных обновилась, и перейдут в состояние «Needs Attention». Теперь вам потребуется обновить все агенты. Это можно сделать удаленно из консоли, выбрав узлы со статусом «Needs Attention» и выполнив действие «Update Agent». Не рекомендую обновлять за раз слишком много агентов, лучше делать это группами по 15-25.

Обновление кандидата для выпуска SCVMM 2008 R2 (Release Candidate, RC) до окончательной версии

Процесс обновления с версии Release Candidate потребует использования дополнительной утилиты «UpgradeVMMR2RC.exe». Взять её  можно там же, откуда вы в своё врмя загрузили сам дистрибутив VMM RC, — а именно, на сайте Microsoft Connect.

Перед обновлением не забудьте сделать резервную копию базы данных VMM.

Теперь вы должны удалить компоненты кандидата для выпуска VMM 2008 R2, при этом обязательно задействовав возможность сохранения базы данных (Retain DB). Потребуется удалить все роли — сервер, библиотеку, портал и консоль администратора.

Далее вам необходимо обновить базу данных при помощи утилиты «UpgradeVMMR2RC.exe». Для этого в контексте администратора выполните следующую команду, указав название базы данных, а также адрес сервера (и, при необходимости, имя экземпляра).

UpgradeVMMR2RC.exe –server <computername[\instancename]> -database <database>

Например, это может выглядеть так: UpgradeVMMR2RC.exe –server VMMDB01\MICROSOFT$VMM$ -database VirtualManagerDB

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

После того, как вы переустановили сервер и все дополнительные компоненты, вам требуется из консоли администратора обновить список управляемых узлов. Это делается так же, как описано в предыдущем сценарии. Можно обновлять агентов группами по 15-25 за раз.

Если некоторые узлы вместо состояния «Needs Attention» отображают состояние «Access Denied», вам требуется перед обновлением перепривязать (Reassociate) агентов к новому серверу.

Обновление 180-дневной ознакомительной (Evaluation) версии или издания Workgroup до VMM 2008 R2 Enterprise

Если у вас установлена 180-дневная ознакомительная версия VMM 2008 R2, или издание Workgroup, то вам потребуется удалить её с сохранением базы данных (Retain DB) так же, как и в предыдущем сценарии. Далее установите полную версию SCVMM 2008 R2 Enterprise с использованием существующей базы данных.

Далее, как описано выше, вам потребуется в консоли администратора обновить список узлов в дереве Hosts и в дереве Library, перепривязать (Reassociiate) те узлы, которые находятся в состоянии «Access Denied», а затем обновить их («Update Agent»).

Интеграция с System Center Operations Manager (OpsMgr)

Если у вас была настроена интеграция VMM 2008 или VMM 2008 R2 RC с Operations Manager, то после обновления до окончательной версии VMM 2008 R2 вам потребуется импортировать обновленные пакеты управления (Management Packs) в OpsMgr. Имейте в виду, что сам VMM будет рапортовать, что интеграция с OpsMgr работает корректно, так как не проверяет версию пакетов управления в OpsMgr. Я бы рекомендовал в консоли оператора OpsMgr сначала удалить старые VMM Management Packs, а затем вручную импортировать новые.

Затем завершить настройку выполнением двух коммандлетов PowerShell:

# Get-VMMServer -ComputerName NAMEOFYOURVMMSERVER

# Set-VMMServer -OpsMgrServer NAMEOFYOURSCOMSERVER

На этом мы закончим обновлять SCVMM до версии R2. Отдельные тонкости могут возникать при обновлении с более ранних предварительных версий (Beta), а также при обновлении агентов на кластерах. Рекомендую ознакомиться с VMM Upgrade Guide.

System Center Virtual Machine Manager 2008 R2 и Microsoft Hyper-V Server 2008 R2 доступны для загрузки

Вчера на подписках MSDN и TechNet появился долгожданный System Center Virtual Machine Manager 2008 R2. В отличие от версии для ознакомления, опубликованной ранее, это — полнофункциональный дистрибутив без ограничений по времени использования. Поэтому теперь вы можете вплотную заняться тестированием и обкаткой решений, построенных на второй версии платформы виртуализации Microsoft. Выглядит это примерно так:

System Center Virtual Machine Manager 2008 R2 (x64) - DVD (Chinese-Simplified, Chinese-Traditional, English, French, German, Italian, Japanese, Korean, Spanish)
09-08-2009
3,395.68 (MB)
File Name: mu_system_center_virtual_machine_manager_2008_r2_x64_dvd_x15-83150.iso
Date Posted (UTC): 9/8/2009 12:13:25 PM
SHA1: 3A1D2D0B08832BB5054E6357FE4027BCDCBB7F94
ISO/CRC: N/A
Available to Levels: TechNet Plus SA Media; TechNet Plus (Retail); TechNet Direct (Retail); TechNet Plus (VL); TechNet Plus Direct (VL); TechNet Cert Partner; TechNet Gold Cert Partner; TechNet Plus Consumer Service Professional Pilot;

Кстати говоря, немного раньше была выложена и окончательная версия Microsoft Hyper-V Server 2008 R2. Вы можете загрузить её через сайт Microsoft Download Center. Требуется короткая регистрация, но этот продукт как был, так и остался бесплатным.

Скидки на сертификационные экзамены Microsoft

Открыта новая рекламная кампания программ сертификации Microsoft. В её рамках все желающие могут получить скидку в размере от 15% до 25% на сдачу ряда сертификационных экзаменов по тем или иным продуктам и технологиям Microsoft. Список экзаменов довольно обширный, акция действует до конца года. Однако, количество ваучеров ограничено, поэтому рекомендую не особо откладывать регистрацию. Точный размер скидки зависит от конкретного экзамена. Например:

Скидка 15%

Exam 70-680: TS: Windows 7 Configuring;
Exam 70-656: TS: Microsoft Desktop Optimization Pack, Configuring (основная тема экзамена — технология виртуализации приложений Microsoft App-V, бывшая Softricity SoftGrid);
Exam 70-652: TS: Windows Server Virtualization, Configuring (это экзамен по технологиям Hyper-V, мы писали о нём достаточно подробно вот здесь и ранее здесь).

Скидка 20%

Exam 70-403: TS: System Center Virtual Machine Manager 2008, Configuring (подробнее здесь).

Скидка 25%

Никаких новых или релевантных тематике нашего блога экзаменов там нету, так что смотрите полный список: Career Campaign: Certification Exam Offer. Подробности об условиях участия в акции — там же. Желаем успешной сдачи экзаменов!

Добавлено в 12:45

Вот как это примерно должно выглядеть при регистрации на экзамен. Для проверки была взята скидка 20%.

Вышла окончательная версия второго выпуска служб интеграции Hyper-V для Linux

Чтобы до поры до времени закрыть тему совместимости с Linux, поднятую в предыдущей новости, нельзя не упомянуть ещё об одном событии, которое могло пройти незамеченным. Пару дней назад вышла окончательная версия второго выпуска служб интеграции Hyper-V для Linux. Показательно, что дистрибутив служб интеграции для Linux был впервые размещён в Центре загрузки Microsoft. Напомню, что даже окончательная версия первого выпуска служб интеграции для Linux, разработанных компанией Citrix для первой версии Hyper-V, была доступна только через сайт Microsoft Connect.

Обо всех отличиях и новых возможностях второго выпуска служб интеграции для Linux мы уже писали чуть ранее, после выхода предварительной версии. Стоит, однако, упомянуть два любопытных факта. Во-первых, окончательная версия второго выпуска служб интеграции вполне закономерно поддерживается и при работе с окончательным выпуском второй версии Hyper-V. Во-вторых, нельзя не отметить, что согласно результатам внутреннего тестирования, производительность второй версии возрасла буквально в разы. А именно, было зафиксировано увеличение производительности сетевой подсистемы на 500% и системы работы с хранилищами на 200% по сравнению с первой версией служб интеграции Hyper-V для Linux. Очевидно, что это является следствием не только тщательной оптимизации кода, но и смены архитектуры в пользу отказа он прослойки, работающей через адаптер гипервызовов Xen.

Также важно понимать, что текущая версия служб интеграции для Linux поддерживается только при установке на SUSE Enterprise Linux Server версий 10 SP2 и 11 (как х86, так и х64). Что же касается Red Hat Linux, то у этого производителя имеется ещё одно существенное требование. Для всех устройств, претендующих на сертификацию для работы с Red Hat Linux, драйверы должны быть включены в ядро Linux. Таким образом, на сегодня Red Hat Linux поддерживается в Hyper-V лишь при использовании эмулируемого оборудования (на то оно и эмулируемое, чтобы эмулировать наиболее распространнёные модели оборудования и обеспечивать работу максимально широкого ряда ОС). А для установки синтетических устройств следует сначала дождаться завершения начатого месяц назад процесса по включению кода служб интеграции в ядро Linux, и только после этого тестировать их на совместимость с дистрибутивами Red Hat. Точные сроки пока что неизвестны, но Microsoft планирует окончить эту работу до конца 2010 финансового года (т.е. к июлю 2010 календарного года).

Hyper-V официально сертифицирован RedHat как поддерживаемая платформа

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

На днях в список поддерживаемых платформ на сайте RedHat вошли версии Hyper-V и Hyper-V R2 — как в виде роли полнофункциональной Windows Server, так и отдельного бесплатного продукта Hyper-V Server.

Если посмотреть чуть глубже, то увидим:

Предворяя различные обсуждения, отмечу, — действительно, пока что платформа Hyper-V сертифицирована лишь как набор эмулируемого оборудования. То есть, синтетические устройства, для работы которых требуются службы интеграции, пока что не поддерживаются официально. Но процесс сертификации служб интеграции в RedHat идет полным ходом, и мы обязательно отметим его завершение. Очевидно, что финальным аккордом тут станет публикация служб интеграции уже в составе поддерживаемого RedHat ядра Linux.

Кстати, не удержусь заметить, что лишь на виртуальной платформе Hyper-V на данный момент поддерживается работа последней версии RedHat Enterprise Linux 5.2. На гипервизорах конкурентов поддерживается кое-где версия 5.0, а кое-где версия 5.1.

Окончательная версия System Center Virtual Machine Manager (SC VMM) 2008 R2

Сегодня было объявлено о завершении работы над вторым выпуском (R2) серверного продукта Microsoft для централизованного управления инфраструктурой виртуалзиации под названием System Center Virtual Machine Manger (SC VMM) 2008. Теперь он уходит в производство (RTM) и станет доступен для коммерческого использования (GA) с первого октября 2009 года. В этот день корпоративные заказчики уже смогут загрузить полнофункциональный дистрибутив. Но версия для ознакомления доступна всем желающим прямо сейчас.

Обо всех новых возможностях этой версии продукта мы уже писали. Однако, и здесь не обошлось без сюрпризов, и в окончательной версии была добавлена одна, но очень важная и долгожданная функция. А именно — официальная поддержка VMware vSphere 4.0. Теперь SCVMM 2008 R2 умеет корректно работать с новым семейством продуктов серверной виртуализации VMware. Пока что это обеспечено в том же объёме, как и работа с VMware Virtual Infrastructure 3.x. То есть надо понимать, что поддержка всех новых функций пока не реализована, но работа над этим будет продолжена.

Заметки о выпуске и дистрибутив для ознакомления

• System Center Virtual Machine Manager 2008 R2 Release Notes;
• System Center Virtual Machine Manager 2008 R2 – Evaluation.

Документация

• System Center Virtual Machine Manager 2008 R2 Cmdlet Reference;
• VMM2008 R2 - Building PRO-Enabled Management Packs;
• также обновлён соответствующий раздел библиотеки Microsoft TechNet. Теперь он официально называется System Center Virtual Machine Manager 2008 and Virtual Machine Manager 2008 R2.

Обзорная вебтрансляция

Вебтрансляция под названием «Technical Overview of System Center Virtual Machine Manager 2008 R2» состоится девятого сентября в 10:00 по летнему тихоокеанскому времени (PDT) — это 20:00 в Москве. Заявлен уровень сложности 300, что подразумевает достаточно глубокую техническую информацию.

Добавлено в 11:45

• VMM 2008 R2 Upgrade Guide.

Установка OpsMgr 2007 R2 и OpsMgr Reporting

Мы уже рассматривали процесс установки OpsMgr 2007 под Windows Server 2008, теперь же посмотрим, насколько проще стала процедура с выходом OpsMgr 2007 R2. Сейчас у нас есть установленный SQL Server 2008 с Reporting Services, а также весь необходимый набор доменных учетных записей, созданных на предыдущем шаге. Приступаем к установке OpsMgr 2007 R2. Для начала нам потребуется загрузить с сайта Microsoft и установить ASP.NET Ajax Extensions 1.0 для ASP.NET 2.0.

Далее запускаем установку OpsMgr 2007 R2 и убеждаемся, что наша система совместима с ним.

Для задач виртуализации нам потребуются все компоненты, кроме OpsMgr Web Console. Если вы предпочитаете наблюдать за серверами удаленно через веб-интерфейс, то можно добавить и консоль.

На стадии установки необходимо указать имя нашей группы управления (Management Group) OpsMgr.

Далее нужно указать учетную запись (созданную на предыдущем шаге), в контексте которой будут запускаться привилегированные задачи (то есть, отдельные процессы MonitoringHost.exe). Сразу замечу — это не то же самое, что учетная запись службы агента (HealthService):

А затем — учетные записи для служб OpsMgr SDK и Configuration (для этого мы на прошлом этапе создали учётную запись OpsMgrSDKConfig):

При установке OpsMgr Reporting указываем созданные ранее учетные записи DWDataWriter и DWDataReader.

После установки OpsMgr для задач виртуализации нам потребуется из консоли администратора добавить следующие Пакеты управления (Management Packs):

• Windows Server Internet Information Services 2003,
• Windows Server 2008 Internet Information Services 7.0,
• Windows Server Internet Information Services Library,
• SQL Server Core Library,
• Windows Server 2008 Operating System (Discovery),
• Windows Server Operating System Library.

На этом процесс установки OpsMgr 2007 R2 закончен. После этого следует установить агентов OpsMgr на серверы виртуализации и в виртуальные машины для сбора информации о производительности. Если планируете при помощи OpsMgr решать также задачу мониторинга работы других служб ОС и серверных продуктов, вам может потребоваться установить дополнительные пакеты управления.

На следующем этапе мы займемся установкой самого System Center Virtual Machine Manager 2008 R2.

Установка SQL Server 2008 для SCOM 2007 R2 и SCVMM 2008 R2

Мы с вами уже рассматривали сценарии установки SQL Server 2005 для System Center Operations Manager 2007 и System Center Virtual Machine Manager 2008. Сейчас в свете появления новых продуктов в линейке System Center возникает необходимость освежить эти статьи, но теперь мы будем опираться на уже следующее поколение сервера работы с базами данных — Microsoft SQL Server 2008. В этой статье я расскажу вам о том, как установить SQL Server 2008 для использования с OpsMgr 2007 R2 и VMM 2008 R2. Я надеюсь, что вы уже ознакомились с моей заметкой об интеграции обновлений в SQL Server 2008, так что сейчас я не буду останавливаться в статье на версиях SQL. Считаем, что у вас уже есть дистрибутив, актуальный на данный момент времени.

Предварительные шаги

Перед тем, как начать процесс установки SQL Server 2008 для задач виртуализации, мы должны создать в домене необходимый набор учетных записей. Технически, возможно использование и локальных учетных записей сервера, но возникнут определенные сложности с прописыванием SPN, да и разнести роли в таком случае будет практически невозможно. Я рассматриваю рекомендуемый Microsoft способ установки — с использованием доменных учетных записей. Итак, нам потребуется создать

• глобальную группу «OpsMgrAdmins»

и следующих пользователей:

• OpsMgrSDKConfig — обычный пользователь домена, локальный администратор на сервере с OpsMgr и член группы OpsMgrAdmins;
• DWDataReader — обычный пользователь домена;
• DWDataWriter — обычный пользователь домена;
• OpsMgrAction — обычный пользователь домена, локальный администратор на сервере с OpsMgr и член группы OpsMgrAdmins;
• VMMService — обычный пользователь домена, локальный администратор на сервере с VMM и член группы OpsMgrAdmins.

Установка SQL Server 2008

Запускаем мастер установки SQL Server 2008 из папки с интегрированным дистрибутивом в контексте пользователя с правами администратора. Принимаем условия установщика, доставляем необходимые компоненты .NET Framework и Windows Installer и перезагружаемся при необходимости. Далее выбираем необходимые нам компоненты SQL Server 2008, как показано на следующем рисунке.

Принимаем значения по умолчанию для имени экземпляра SQL Server, выбираем диск для установки, указываем тип запуска служб SQL Server в контексте локальной системы (Local System).

Далее мы должны выбрать режим аутентификации Windows (Windows Authentication Mode) и указать пользователя, являющегося администратором SQL Server. Это может быть встроенная учетная запись администратора сервера, специальный доменный пользователь или любая группа.

Устанавливаем SQL Server 2008 Reporting Services в конфигурации по умолчанию.

Далее дожидаемся окончания процесса установки SQL Server 2008.

Если вы не подготовили интегрированный дистрибутив с пакетом обновления SQL Server 2008 Service Pack 1 и последним накопительным обновлением (Cumulative Update), то вам потребуется установить их после установки. О том, где достать необходимые обновления, читайте в той же статье про интеграцию обновлений в SQL Server 2008.

В отличии от сложной конфигурации IIS для SQL Server 2005 Reporting Services, в случае со SQL Server 2008 никаких дополнительных настроек не потребуется. Можно проверить доступность SQL Server 2008 Reproting Services по ссылке http://localhost/reports, а затем с другого компьютера — по адресу http://<адрес сервера>/reports. Если все работает, то в обоих случаях вы увидите примерно такую страницу.

На этом настройка SQL Server 2008 завершена. Дальше можно переходить к установке OpsMgr R2 и SCVMM R2. Но об этом мы поговорим в следующий раз.

Кандидат для выпуска Windows Virtual PC и Windows XP Mode

Завтра сразу несколько категорий заказчиков и партнёров смогут получить доступ к дистрибутивам Windows 7 и Windows Server 2008 R2, а вчера Microsoft объявила о появлении Кандидата для выпуска (Release Candidate) двух важных дополнительных частей «мозаики» экосистемы Windows 7. Речь идёт о совместимых выпусках бесплатной системы настольной виртуализации Windows Virtual PC и производной от неё функции Windows XP Mode.

Среди изменений в этом выпуске по сравнению с предыдущей предварительной версией достаточно значителен.

• Управление устройствами USB при работе с виртуальными приложениями, запущенными в оконном режиме;
• список быстрого перехода (Jump List) между виртуальными приложениями на панели задач;
• настройки общего доступа к локальным дискам;
• встроенное руководство по использованию Windows XP Mode;
• ускоренная установка Windows XP Mode;
• функция сжатия разностных (Differencing) виртуальных дисков;
• установка дополнительных компонентов в Windows XP Mode;
• выбор пути для установки Windows XP Mode.

Ссылки

• Официально объявление о выпуске Windows Virtual PC и Windows XP Mode в блоге команды разработчиков Windows: Windows XP Mode RC Now Available;
• страница загрузки: Download Windows Virtual PC RC and Windows XP Mode RC;
• заметки к выпуску: Release Notes for Windows Virtual PC RC and Windows XP Mode RC;
• инструкция по установке и настройке: Windows Virtual PC RC and Windows XP Mode RC Setup and Installation Guide;
• новый блог на сайте TechNet: подробно про Windows Virtual PC.

Опубликована вторая версия Служб интеграции Hyper-V для Linux

Сегодняшняя новость уже успела вызвать неслабый ажиотаж в некоторых кругах. Шутка ли — Microsoft заявила о том, что вносит свой вклад в ядро Linux на условиях General Public License (GPL) 2. Речь идёт, ни много ни мало, о примерно двадцати тысячах строках кода.

Открыты исходные тексты служб интеграции для Hyper-V, и драйверы для синтетических устройств внесены на рассмотрение разработчиков Linux для включения в следующие версии ядра. В разультате службы интеграции Hyper-V станут доступны как в будущих версиях популярных дистрибутивов Linux, так и вообще в любых системах — при сборке ядра с соответствующими условиями.

Что было раньше?

Для того, чтобы правильно понять то, о чём было объявлено сегодня, потребуется разобраться и в том, что же было до того. И начать придётся с понимания того факта, что это уже вторая версия Служб интеграции Hyper-V для Linux.

Что стало теперь?

Сегодня Microsoft опубликовала дистрибутив второго Кандидата для выпуска (Release Candidate 2, RC2) второй версии Служб интеграции Hyper-V для Linux. Кроме того, корпорация предложила его исходный текст для включения в ядро Linux. Фактически речь идёт об одном и том же коде, представленном в двух вариантах для двух разных аудиторий и целей.

Но зачем?

Вы можете поинтересоваться — какая в этом выгода для Microsoft. Ведь Linux всегда был конкурентом Windows — так зачем же за свой счёт облегчать жизнь как разработчикам, так и пользователям конкурирующего продукта?

Дело в том, что эпоха ожесточённой конкуренции на рынке ОС уже фактически в прошлом. Ниши чётко поделены, и по собственной статистике Microsoft в около 80% виртуальных машин запущены различные версии Windows. Для того, чтобы изменить баланс сил, потребовалось бы приложить огромные усилия. Они в любом случае не окупятся за счёт тех долей процента, которые можно было бы выиграть тем или иным образом.

Зато виртуализация — это сравнительно молодая и очень быстро растущая отрасль. И вот здесь конкуренция даёт о себе знать очень остро. Поэтому представить условия для установки любых продуктов поверх своего решения — это очень хороший ход.

Теперь получается, что в недалёком будущем практически любая версия Linux прямо «из коробки» будет отлично работать в виртуальных машинах Microsoft. Во-первых, это даст сильное преимущество перед конкурирующими решениями для виртуализации, если их разработчики не смогут быстро предоставить такое же удобство своим пользователям. А во-вторых, это страхует Microsoft против возможных упрёков во включении служб интеграции в состав своих собственных ОС, что тоже немаловажно.

Но как?

Некоторые технические и организационные подробности для тех, кому близка тема свободных ОС. Текущая версия Служб интеграции Hyper-V для Linux включает три драйвера.

• VMBus (высокопроизводительная шина данных для обмена информацией между ВМ и родительской системой);
• синтетический сетевой контроллер;
• синтетический контроллер дисков с поддержкой быстрой загрузки (FastPath).

Вообще говоря, Linux может работать в виртуальных машинах Hyper-V и без этих драйверов, что уже было неоднократно подтверждено различными энтузиастами. Разница только в производительности — ведь без драйверов синтетических устройств вы сможете использовать только их эмулируемые аналоги. В частности, придётся в явном виде добавить в ВМ эмулируемую сетевую карту, а подсистема работы с дисками хоть и не потребует каких-то изменений в конфигурации ВМ, но просто будет вынуждена работать через обычные драйверы.

Код, предложенный Microsoft, будет добавлен в ядро Linux версии 2.6.32 через Linux Driver Project. Как следует из названия, это команда разработчиков, которые занимаются добавлением и поддержкой драйверов в ядре Linux. Если быть ещё более точным, то со стороны сообщества Linux с программистами Micorosft тесно сотрудничал Грег Кроа-Хартман (Greg Kroah-Hartman).

Более того, Microsoft берёт на себя обязательства и в дальнейшем поддерживать и улучшать код служб интеграции. Для чего специально выделены два сотрудника из лаборатории Microsoft, расположенной в Кэмбридже, штат Массачусетс. Хэнк Джансен (Hank Janssen) и Хайанг Янг (Haiyang Zhang) официально назначены специалистами по поддержке (maintainer) проекта служб интеграции Hyper-V для Linux. В планах по дальнейшему развитию значится добавление таких функций, как:

• симметричная многопроцессорность (SMP). Сегодня в Hyper-V поддерживаются только ВМ с Linux, использующие один вирутальный процессор;
• дополнительные службы, а именно:
  • завершение работы гостевой ОС по сигналу из родительской системы (Shutdown);
  • обмен парами ключей и значений (KVP Exchange).

По мере завершения работы над этими функциями их код будет так же направляться для включения в ядро Linux.

Важно понимать, что ещё одно популярное дополнение, которое является частью Служб интеграции для Windows, не входит в комплект Служб интеграции для Linux. Речь идёт о драйвере для мыши, также известном как InputVSC. Он позволяет переносить указатель мыши между окнами виртуальной машины и рабочим столом родительской системы без необходимости предварительно извлекать его с помощью клавиатурной комбинации. Также он решает распространённую проблему, которая заключается в том, что мышь вообще не работает в окне подключения к виртуальной машине (VMConnect), открытом через сеанс «Удалённого рабочего стола» (Remote Desktop). Этот драйвер разработан отдельно компанией Citrix в рамках «Project Satori». Вы можете загрузить его на сайте Служб интеграции Citrix для Hyper-V.

Дополнительная информация

• Официальный пресс-релиз: Microsoft Contributes Linux Drivers to Linux Community;
• видеозапись интервью с Томасом Ханраханом (Tom Hanrahan), директором Технологического центра открытых исходных текстов Micorsoft на сайте Девятого канала: Microsoft Contributes Code to the Linux Kernel;
• Microsoft Releases Device Driver Code to the Linux Community;
• More on the Hyper-V Linux Integration Components.

Вышел Microsoft Assessment and Planning (MAP) Toolkit 4.0

Первая ласточка новой линейки продуктов, которую мы все ждём буквально со дня на день. Четвёртая версия популярного бесплатного инструмента для проведения инвентаризации, оценки и анализа инфраструктуры теперь полностью поддерживает новое поколение ОС Windows — а именно:

• Windows 7;
• Windows Server 2008 R2;
• вторая версия Hyper-V, встроенная в Windows Server 2008 R2.

Прочие новые возможности:

• Интеграция с инструментом подсчёта возврата инвестиций (Virtualization ROI Calculator), расположенном в Интернете;
• обнаружение виртуальных машин VMware;
• инструментарий дополнительной настройки отчётов для партнёров Microsoft;
• улучшения производительности.

Ссылки:

• Домашнаяя страница MAP;
• техническая информация;
• запись обзорной вебтрансляции по предварительной версии MAP 4.0;
• загрузить Microsoft Assessment and Planning Toolkit.

Запрет смены пароля ОС для предотвращения устаревания снимков и неиспользуемых ВМ

Периодически я сталкиваюсь с ситуацией, когда пароль компьютера в локальном хранилище теряет синхронизацию с доменом. Это происходит как при восстановлении старого снимка (snapshot) виртуальной машины, так и просто при запуске тестовой машины, которая не включалась несколько месяцев. Результатом обычно бывает недоступность домена, что исправляется выводом ВМ из домена и повторным присоединением.

Технически данная проблема вообще не связана с виртуализацией. Если вы выключаете любой доменный компьютер более, чем на 60 дней, то при включении он может быть не принят контроллером в виду проблем с так называемы «безопасным каналом» (secure channel). Если же вы используете снимки в виртуальных машинах, то в течении 30 дней с момента создания снимка компьютер должен сменить свой пароль в домене, После чего, применив снимок, вы уже не сможете зайти в домен. Сегодня мы рассмотрим эту проблему и способы ее решения.

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

Computer Configuration\windows Settings\Security settings\Local Policies\Security Options - Domain member: Disable machine account Password changes

Сами контроллеры домена никогда не меняют паролей учётных записей компьютеров домене.

Как же происходит процедура смены паролей? При старте службы NetLogon инициируется Workstation Scavenger. Если пароль системной учетной записи уже старее чем значение MaximumPasswordAge, то Scavenger инициирует обращение к контроллеру домена с запросом смены пароля. Если контроллер недоступен, или отвечает отказом на запрос о смене пароля, то Scavenger заново обратится к контроллеру через интервал времени (в минутах), указанный в ключе ScavengeInterval. Если на момент старта NetLogon пароль еще не устарел, то Scavenger обратится к контроллеру за сменой пароля как раз в момент его устаревания. По умолчанию для Windows NT 4.0 ScavengeInterval был равен 7 дням, а начиная с Windows 2000 увеличен до 30 дней. Этот интервал можно изменить следующей политикой:

Computer Configuration\Administrative Templates\System\Netlogon\Scavenge Interval

Если вы хотите запретить всем компьютерам домена менять пароли, то можно на контроллерах домена создать ключ RefusePasswordChange. Контроллеры перестанут отвечать на запросы Scavenger на смену пароля.

Наконец, на каждом конкретном компьютере можно создать ключ реестра DisablePasswordChange, выставив который в единицу, вы добьетесь того, что данный компьютер не будет менять пароль своей системной учетной записи. Соответственно, он не «вылетит» из домена, даже если вы его не включали несколько лет, или применили старый снимок состояния системы. Это также можно настроить доменной политикой:

Computer Configuration\windows Settings\Security settings\Local Policies\Security Options - Domain member: Disable machine account Password changes

Очевидно, что все вышесказанное относится к ОС Windows, — как на физическом оборудовании, так и в виртуализации, причём не только Hyper-V, но и сторонних поставщиков.