Обновление: Записи доступны по ссылкам:
UC². Встреча №20. Александр Перчиков. Polycom + Skype for Business = законченное UC решение
UC². Встреча №20. Сергей Росин. Microsoft Teams, Skype Operations Framework, Skype для Бизнеса
UC². Встреча №20. Vadims Podans. AD CS Web Services
UC². Встреча №20. Сергей Груздов. Программно-определяемые сети

В очередной раз объединяемся с группой IT Pro. Докладчиков будет четверо. Формат встречи – онлайн. Дата встречи – как обычно, последний вторник месяца, 29 ноября. Начало – 15-00.

Расписание встречи следующее:

15:00-16:30 Polycom + Skype for Business = законченное UC решение. Александр Перчиков, Руководитель Центра Решений и Технологий Polycom.

  • Решения Polycom для реалистичной видеосвязи
  • Аудио и видео периферия для Skype For Business
  • Интеграция сред SfB и «классической» ВКС

16:30-18:00 Microsoft Teams, Skype Operations Framework, Skype для Бизнеса в составе пакета Click-To-Run. Сергей Росин, Technical Solutions Professional – Communications Microsoft Russia.

Будут затронуты следующие темы:

Microsoft Teams – Новое решение для совместной работы на базе мгновенных сообщений

  • Описание решения
  • Возможности
  • Рекомендации к развертыванию

Skype Operations Framework – Методология для корректного развертывания Skype для Бизнеса в облаке

  • Описание методологии
  • Описание набора документации в методологии

Skype для Бизнеса в составе пакета Click-To-Run. Уникальные возможности, которых нет MSI пакете Office 2016 Pro Plus.

18:00-19:30 ADCS Web Services – шаг в открытые сети. Вадимс Поданс, восьмикратный MVP.

План доклада:

  • Краткий экскурс в историю с основными вехами развития ADCS начиная с NT4 с обсуждением наиболее важных и насущных проблем совместимости и безопасности ADCS
  • Краткий обзор ADCS Web Services
  • Описание новых сценариев использования ADCS для недоменных клиентов
  • Более детальный разбор ADCS Web Services при внедрении
  • Демонстрация

Описание от автора: «Веб-службы ADCS позволяют раздвинуть границы использования Microsoft CA за пределы периметра с возможностью интеграции и совместимости со сторонними гетерогенными системами. Объясню. Расскажу. Покажу».

19:30-21:00 Эволюция SDN в Windows Server: Network Controller. Сергей Груздов, ведущий инженер, Dataline.

Тезисы: Новое Software Defined Network v2 в Windows Server 2016: Network Controller, Software Load Balancing, GRE/SSTP/IPSEC VPN, поддержка VXLAN

Идея виртуализации сетей берет свое начало со статических VLAN, однако облачная среда нуждается в более гибких и безопасных решениях сетевой виртуализации. Уже в Windows Server 2012 сетевая виртуализация Hyper-V поддерживала формат инкапсуляции NVGRE. Windows Server 2016 работает и с другим перспективным стандартом инкапсуляции – VXLAN, позволяющим обмениваться туннельными конечными точками (VTEP) между виртуальными машинами и физическими устройствами.  Network Controller, о котором пойдет речь в докладе, представляет собой программируемую среду для управления такими виртуальными сетями и применения детальных политик, определяющих доступ, балансировку нагрузки и Quality of Service. Многие производители включают поддержку стандарта VXLAN в свои сетевые адаптеры и активное сетевое оборудование.

Ссылка на мероприятие – тут.

Предыдущие версии гипервизора от MS (идущие в комплекте с Windows 2008 и Windows 2008 R2) обрабатывали удаление снимков виртуальных машин достаточно криво – необходимо было сразу после удаления снимка выключать виртуальную машину. В процессе выключения данные из снимка объединялись с родительским файлом vhd или avhd. Понятно, что после удаления снимка выключать виртуальную машину не всегда было возможно. В итоге могло быть несколько удалённых снимков, которые так и не были объединены в родительский файл. И вот в этот момент слияние всех этих оставшихся файлов превращалось в настоящий квест.

Относительно недавно стал доступен дистрибутив для разработчиков следующей версии Windows Server со следующей версией гипервизора на борту. Вот тут в комментариях Александр Станкевич задал интересный вопрос – “Раз уж появились различные “живые сценарии”, то и слияние (Merge) дисков, после удаления Snapshot’ов, теперь будет выполняться без необходимости выключения виртуальной машины?”

Вроде бы пока я не видел чтобы это утверждение кто-то проверил – так что, возможно, буду первым.

Что у нас имеется – свежеустановленная операционная система Windows Server 8 Developer Preview с ролью Hyper-V. Далее подключаем её в качестве хоста к VMM 2008 R2 (подключается!) и заливаем из библиотеки виртуальную машину. Так получилось, что это оказалась Windows 2003. Далее ставим разное ПО чтобы можно было сделать пару снимков, которые бы друг от друга немного отличались. В итоге получаем следующее. Имеется 2 снимка:

Физически они все три состояния виртуальной машины представляют три файла:

Первый файл – 2003std86.vhd – представляет собой состояние виртуальной машины на момент создания снимка “with Outlook”, второй файл представляет собой изменение состояния виртуальной машины на момент создания снимка “win2003test”, ну и в третьем файле находится изменение состояния виртуальной машины на текущий момент со времени предыдущего снимка.

Логично предположить, что если мы будем удалять второй снимок – то в его файл должно вставиться изменение состояния виртуальной машины из третьего файла. Если будем удалять только первый снимок – то второй файл будет объединён с первым. Попробуем удалить снимок “win2003test”. После удаления в поле статуса виртуальной машины появится текст “Merge in Progress”:

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

Видно, что третий файл был объединён со вторым, за счёт чего последний стал чуть больше. Ну и для закрепления удалим оставшийся первый снимок “with Outlook”. Опять в поле статуса виртуальной машины появится “Merge in Progress” и по завершении у нас останется только один файл:

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

При корректном удалении снимков виртуальной машины при её выключении снимки жёстких дисков должны объединяться автоматически. К сожалению, не всегда это получается и в силу разных причин папка со снимками может распухать и привести ко всяким неприятным последствиям. Инструмента по автоматическому объединению таких “бесхозных” снимков нет. Приходится делать объединение вручную. Для этого необходимо знать где находятся снимки жёстких дисков (находятся обычно в папке виртуальной машины в подпапке Snapshots) и где находится исходный vhd-файл, к которому эти снимки мы будем прикреплять. Так же необходимо понять в каком порядке объединять снимки. Сначала объединяем самый свежий снимок (дата изменения снимка при включённой виртуалке совпадает с текущей, например 20/05/2010) со снимком более старшим (дата изменения снимка меньше предыдущей, но больше остальных, например 15/05/2010). Получившийся в итоге снимок объединяем со следующим по старшинству. Процедуру повторяем до тех пор пока не остается один снимок, который объединяется с исходным vhd-файлом. Процедура получается следующая:

  1. Выключаем виртуалку, чьи диски-снимки надо объединить.
  2. Меняем расширения всех снимков с .avhd на .vhd.
  3. На всякий случай делаем копии всех преобразуемых файлов (бывших .avhd и исходных .vhd).
  4. Записываем порядок в котором быдем объединять диски (20/05/2010.vhd => 15/05/2010.vhd =>… => Virtual Disk.vhd), чтобы в процессе не сбиться.
  5. В оснастке Hyper-V запускаем Edit Disk, выбираем самый новый снимок (20/05/2010.vhd). В окне выбора действия будет доступно только одно действие – Reconnect. Далее надо будет указать родительский снимок (предыдущий относительно того, который последний – 15/05/2010.vhd). При этом, для облегчения выбора, будет подсказка какой диск является родительским к исходному. Выбираем его. Нажимаем Finish.
  6. Запускаем Edit Disk повторно, выбираем самый свежий снимок. В окне выбора действия должно появится 2 пункта – Compact и Merge. Нас интересует второй. Выбираем его. В окне Summary можно будет посмотреть какой снимок с каким объединяется. Убеждаемся что это нужные нам снимки и запускаем процесс. При больших размерах снимков процесс может длиться достаточно долго.
  7. По завершении процесса в папке со снимками останется только самый новый снимок (20/05/2010.vhd). Родительский снимок (15/05/2010.vhd) будет удалён. Если в папке остались ещё более старые снимки, то переходим к пункту 5 и повторяем процесс объединения.
  8. Запускаем снова Edit Disk, в окне  выбора действия будет 2 пункта – Compact и Merge. Выбираем второй. По завершении процесса в папке снимков снимков исходного диска не останется – все они будут объединены с исходным vhd-диском.
  9. Теперь, если мы зайдём в свойства виртуальной машины, то при попытке посмотреть на свойства нашего разбитого на снимки диска будет ошибка – виртуалка не сможет найти последний снимок. Смело можно удалять диск из свойств виртуалки и подключать его заново.

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

Windows Server 2008Сделал миграцию (p2v) контроллера домена (Windows 2003 R2 x64 Ent) с помощью SCVMM 2008 R2 на сервер Hyper-V на базе Windows 2008, потом импортировал эту виртуалку на сервер Hyper-V на базе Windows 2008 R2. После этого (и может и сразу после миграции – к сожалению не отследил виртуалка выпадает в BSOD. Ошибку пишет:

STOP: 0x0000007B (0xFFFFFADFEA40F3C0,0xFFFFFFFFC0000034,0x0,0x0)

Делаю загрузку последней успешной конфигурации – грузится, но отсутствуют все устройства, которые устанавливаются Integrational Services. Через Add/Remove Program удаляю сервисы интеграции. Перегружается успешно. Ставлю их опять – находятся все устройства, но при перезагрузке опять появляется BSOD. Как лечить? Переустановить не получится (DC).

На форумах технета навели на отличнейшую ссылку, которая проблему и решила. Решение выглядит следующим образом:

  1. Загружаем виртуалку в режиме LastKnownGoodConfiguration.
  2. Открываем реестр и смотрим следующий ключ HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesWdf01000
  3. Он должен иметь значение WdfLoadGroup. В моем случае (и у автора статьи из ссылки) там было base. Меняем на WdfLoadGroup.
  4. Удаляем Integration Components.
  5. Перегружаем виртуалку в обычном режиме.
  6. Устанавливаем Integration Components заново.

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

scvmmНаконец-таки дошли руки до интеграции SCVMM и OpsMgr. По идее, процесс выглядит достаточно просто – на сервере с OpsMgr ставится интеграционная компонента с диска SCVMM, на сервере с SCVMM ставится консоль OpsMgr. Затем в консоли SCVMM указывается корневой сервер OpsMgr. Всё выглядит просто в случае установки обоих продуктов на один сервер. Если же сервера разные, кроме этого базы хранятся на третьем сервере, то начинаются разные весёлые приключения.

Сам процесс интеграции в простейшем случае (всё на одном сервере) можно посмотреть здесь.

У меня же процесс интеграции застрял на этапе указания корневого сервера OpsMgr. Попытка возвращала ошибку “VMM service does not have necessary privileges to access the Operations Manager SDK service on <servername>. Add VMM service account as an administrator to the Operations Manager Server and try the operation again”. Ниже небольшое описание того, как я ошибку победил.

1. Добавляем в группу локальных администраторов на корневом сервере OpsMgr сервисную учётную запись VMM.

2. Нужно дать права на чтение и на запись SPN для сервисной учётной записи OpsMgr SDK. Делается это через ADSIEdit следующим образом:

  • В разделе Default naming context ищем сервисную учётную запись OpsMgr SDK.
  • В её свойствах на закладке Security переходим в расширенные настройки (кнопка Advanced).
  • Добавляем учётку SELF, на закладке Properties указываем область применения – This object only. Ставим галки Allow напротив Read servicePrincipleName и Write servicePrincipleName.
  • После этого надо перезапустить сервис System Center Data Access на корневом сервере OpsMgr.

3. Создаём доменную глобальную группу VMMAdmins, добавляем в неё сервисную учётную запись VMM и учётную запись сервера VMM (объект компьютер).

4. Добавляем эту группу в Operations Manager Administrators через консоль OpsMgr (Administration => Security => User Roles => Operation Manager Administrators). Опять перезапускаем System Center Data Access (net stop OMSDK && net start OMSDK).

5. Перезапускаем сервер SCVMM, после этого через консоль VMM добавляем сервер OpsMgr, или через PoSh

Set-VMMServer -VMMServer <SCVMM Server> -OpsMgrServer <OpsMgr RMS Server>

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

Windows Server 2008Буквально на днях при обновлении с RC на RTM VMM 2008R2 столкнулся со следующей проблемой. Один из хостов периодически отваливался от VMM. На самом хосте сервис Hyper-V Virtual Machine Management выгружался после двух минут работы. В события при этом шла ошибка:

Faulting application vmms.exe, version 6.0.6001.18221, time stamp 0x499f6aeb, 
faulting module ntdll.dll, version 6.0.6001.18000, time stamp 0x4791adec, 
exception code 0xc0000005, fault offset 0x000000000001e758, process id 0x6ec, 
application start time 0x01ca403665f3fc4e

Гугл сразу вывел на обсуждение проблемы. Как оказалось, такое поведение системы связано с наличием на хосте виртуалки с подключенным SCSI-адаптером, к которому не подключены жёсткие диски. После удаления адаптера проблема исчезла.

scvmmНа днях стала доступна для скачивания триальная версия SCVMM 2008 R2 RTM. Достаточно оперативно обновилась информация о том как обновиться с RC до RTM версии. Процесс выглядит следующим образом:

1. Делаем бэкап базы VMM 2008 R2 RC. На всякий случай. Если что-то пойдёт не так, можно будет откатиться.

2. Удаляем сервер VMM 2008 R2 RC с галочкой “retain db” и остальные установленные компоненты.

3. Обновляем оставшуюся после удаления базу с помощью утилиты UpgradeVMMR2RC.exe (доступна через Microsoft Connect). Для этого из командной строки, запущенной с расширенными привилегиями (Run as Administrator) на компьютере с установленными .NET Framework 2.0 и Microsoft SQL Server tools выполняется команда:

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

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

4. Устанавливаем сервер VMM 2008 R2 RTM, при установке указываем использовать обновлённую базу. Затем консоль управления и, если необходимо, портал самообслуживания.

5. В консоли управления на странице хостов в поле действий обновляем страницу (Refresh), то же самое делаем на странице библиотек.

6. Обновляем агентов VMM на всех хостах. В связи с тем, что процесс обновления агентов влияет на производительность, рекомендуется запускаеть его одновременно не более чем на 25 хостах.

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

Рабочая версия Hyper-V уже несколько месяцев назад вышла, более того – уже успел выйти специфический продукт Microsoft Hyper-V Server 2008. Самое время начинать активно использовать новую технологию виртуализации в рабочей среде. В связи с этим возникает 3, на мой взгляд, стандартных задачи по миграции в виртуальную среду Hyper-V:
1. Миграция с продуктов MS (VirtualPC/Virtual Server 2005).
2. Миграция с продуктов VMWare.
3. Миграция физических компьютеров в виртуальную среду.
К сожалению, найти документации по подобной миграции найти сходу не удалось.

Continue Reading »

Попросили поставить пару виртуальных машин в VMWare Server. Стоит он на Windows Server 2003 Ent sp2. Версия 1.0.7. работаю через Remote Desktop. Подцепил стандартные образы, изменил настройки памяти и процессоров, подправил размеры дисков. Работает. Выключаю. Пытаюсь поставить в свойствах виртуалок, чтобы они запускались от учётки локальной системы. Запускаю. Пустой экран. Закладка виртуалки говорит что работает. Через некоторое время виртуалка начинает пинговаться и потом появляется доступ через Remote Desktop. В VMWare Serve Console по прежнему пустой экран виртуалки.

С сегодняшнего дня стал доступен релиз Hyper-V – достаточно удачного (по сравнению с VirtualServer) решения по виртуализации от Microsoft.
Скачать можно отсюда:
KB950050 — Description of the update for the release version of the Hyper-V technology for Windows Server 2008
Update for Windows Server 2008 x64 Edition (KB950050)
Update for Windows Server 2008 (KB950050)
KB952627 — Description of the Windows Vista Service Pack 1 Management Tools update for the release version of Hyper-V
Update for Windows Vista for x64-based Systems (KB952627)
Update for Windows Vista (KB952627)

У меня Hyper-V RC0 на Win2k8 Server Core крутится уже месяца 2. Пока проблем особых не обнаружил. В ближайшее время обновлюсь и посмотрю что там нового появилось по сравнению с RC0.