Почему?
Практически в каждой компании или организации есть
унаследованные (а, значит, проблемные) бизнес-приложения, поддержка
которых требует от отдела ИТ слишком много сил. В небольших средах,
управляемых «компьютерщиками на все руки», ситуация усложняется
тысячекратно.
Унаследованное ПО замедляет обновление ОС. Если в
компании должно использоваться приложение, которое совершенно точно не
сможет работать в Windows 7, вряд ли вы скоро решитесь на обновление.
Между имеющимися в Windows 7 улучшениями безопасности, управления и
пользовательского интерфейса стоит одно-единственное, глупое и
устаревшее приложение.
Вот причина использовать режим
совместимости с Windows XP. И важно сказать, что это единственная
причина. Когда?
Когда его использовать?
Получив ответ на
вопрос «почему?», разумно задуматься, где приспособить режим
совместимости с Windows XP в своей среде. Когда же следует использовать
это решение? Ответ:в качестве крайней меры.
Используя
локальную копию Windows Virtual PC, режим совместимости с Windows XP
создает полнофункциональный экземпляр другой ОС на рабочем столе
пользователя. Этот экземпляр выполняется как виртуальная машина с
Windows XP и используется исключительно для размещения немногих
проблемных приложений, которые не работают на Windows 7. Таким решением
Microsoft отметает любые возражения, типа «мы не можем обновить ОС,
потому что наши приложения не поддерживают ее». В некотором смысле, это
абсолютно блестящая маркетинговая стратегия. Браво, Microsoft!
Использование
режима совместимости с Windows XP — единственный способ решить
проблему. Если вы следили за последними выпусками моей колонки, то
наверняка заметили, что они посвящены механизмам поставки приложений.
Современные технологии Microsoft значительно расширяют возможности
получения пользователями приложений, выходя за рамки стандартной
установки ПО на локальной машине.
В двух предыдущих выпусках
журнала (TechNet зафевраль
2010 г. и март
2010 г.) обсуждалось, как можно легко использовать службы удаленного
рабочего стола (Remote Desktop Services, RDS) или размещенные в Hyper-V
виртуальные рабочие столы для создания инфраструктуры удаленных
приложений. В такой среде пользователи подключаются к отдельным
приложениями или целым рабочим столам, размещенными на корпоративном
сервере. Поскольку приложения являются удаленными, то пока у
пользователей есть доступ к сети (или даже к Интернету), совершенно
неважно, где физически находятся эти пользователи. Подключенным
пользователи достаточно нескольких движений мышью, чтобы получить доступ
к нужным им инструментам.
Описанные в предыдущих двух выпусках
колонки методы очень важны для понимания сегодняшнего выпуска. Во многом
описанные в них альтернативные механизмы поставки ПО практически
полностью меняют представление о способах подключения пользователей к
нужным им приложениям.
Допустим, в вашей небольшой среде есть три
унаследованных приложения, у которых лишь небольшие различия в
потребностях и характеристиках. Подумайте, как бы вы предоставили
пользователям доступ к этим программам (при условии, что нужно обновить
системы до Windows 7) в следующих условиях:
- Приложение А без
проблем работает в Windows XP или Windows 7, но администрирование его
многочисленных конфигураций и стандартных обновлений — настоящий кошмар.
Вместе с тем, приложение А прекрасно работает в среде Windows Server
2008.
- Приложение B работает в Windows XP, но не в Windows 7. Эта
довольно нересурсоемкая программа и используется небольшим числом
пользователей.
- У приложения C также проблемы с совместимостью с
Windows 7, но, в отличие от приложения B, ему нужны значительные
ресурсы, при этом приложение C нужно только одному или двум
пользователям.
Каждое из этих приложений требует различного
подхода к поставке пользователям. С приложением А должно быть просто.
Поскольку оно работает на Windows Server 2008, то немедленно становится
кандидатом на размещение средствами RDS. А многочисленные конфигурации и
частые обновления позволяют за раз установить все конфигурации на
сервер RDS, что позволит каждому пользователю получить нужное
приложение, а нагрузка на администраторов снизится.
Разобраться с
приложениями B и C будет немного труднее. Они не совместимы с Windows 7,
поэтому не будут работать в Windows Server 2008. Как говорилось,
приложение B нужно небольшому числу пользователей и оно относительно
нересурсоемкое. Это позволяет разместить его в пуле виртуальных рабочих
столов, обслуживаемых Hyper-V и RDS.
У приложения C большая
потребность в ресурсах, что ограничивает число одновременно используемых
виртуальных рабочих столов, которые можно разместить на одном сервере
Hyper-V. Поскольку это приложение необходимо только одному-двум
пользователям, оно становится хорошим кандидатом для размещения в режиме
совместимости с Windows XP.
Как?
Конечно, оптимальный
вариант — ограничение числа приложений, которым нужен режим
совместимости с Windows XP. Это связано с недостатком инструментальных
средств для автоматизации и централизованного управления службами и
виртуальными машинами этого режима. Режим совместимости с Windows XP
предназначен для решения проблем к ограниченным использованием только в
средах малого и среднего размеров.
Развертывание файлов
виртуальной машины на диске клиентов требует выполнения ручных операций
или решений на основе сценариев. Нет инструментов централизованного
управления параметрами или политиками режима совместимости. Придется
вручную устанавливать приложения и исправления на каждый экземпляр
виртуальных машин режима совместимости с Windows XP или задействовать
специализированные средства, такие как Windows Server Update Services
или System Center Essentials.
Также потребуется установить и
управлять средствами защиты на клиентах, такими как брандмауэр и
антивирусное ПО, на каждой виртуальной машине режима совместимости с
Windows XP, а также на самих клиентских машинах, что удвоит нагрузку на
администратора. Также следует не забывать, что режим совместимости с
Windows XP не поддерживает приложения с трехмерной графикой. И, если
среда требует значительной автоматизации или содержит широко
распространенные приложения, следует подумать об использовании средства
Microsoft Enterprise Desktop Virtualization (MED-V), которое доступно
предприятиям только в составе пакета Microsoft Desktop Optimization Pack
(MDOP).
У режима совместимости с Windows XP также серьезные
требования к оборудованию: компьютер должен поддерживать аппаратную
виртуализацию (что можно проверить средствами Microsoft HAV
Detection Tool), процессорных ресурсов и оперативной памяти должно
быть достаточно для одновременной поддержки основной машины и ее
вторичного виртуального образа, и, хотя формально 64-разрядная ОС не
требуется, зачастую без этого не удается обойти ограничения на объем
оперативной памяти, свойственные 32-разрядным операционным системам
Microsoft.
Также могут возникнуть сложности — все зависит
планирования создания виртуальных машин в режиме совместимости с Windows
XP. При каждой установке режима совместимости с Windows XP виртуальная
машина с Windows XP развертывается как VHD-файл. Лицензия на Windows 7
основного компьютера предоставляет пользователю неограниченный доступ к
этой виртуальной машине, но только к ней. Можно создать собственную
нестандартную виртуальную машину для режима совместимости с Windows XP,
но тогда придется потратиться на дополнительную лицензию.
При
установке режима совместимости с Windows XP придется установить Windows
Virtual PC. Все это можно найти на странице загрузки
Windows Virtual PC. Там же есть отдельные ссылки для этих двух
компонентов, причем предлагается сначала установить режим совместимости с
Windows XP.
Рис. 1 Установка
режима совместимости с Windows XP
Установив оба
компонента, откройте Пуск (Start) и запустите Windows XP Mode из папки
Windows Virtual PC. При первом запуске режима совместимости с Windows XP
предлагается указать папку для установки, а также имя пользователя и
пароль учетной записи XPMUser (см. рис. 1). Это
локальная учетная запись в основной ОС, являющаяся членом группы
локальных администраторов. Она будет использоваться для запуска
приложений в режиме Windows XP из основной ОС.
Увеличить
Рис.
2 Окно впервые запущенной гостевой Windows XP
По
завершении мастера установки гостевая ОС по умолчанию будет запущена и
произойдет вход в систему. Окно впервые запущенной гостевой ОС показано
на рис. 2. Машине присваивается имя в формате
\\\\VirtualXP-xxxxx, где xxxxx — случайный набор чисел
Она состоит членом рабочей группы, но ее можно присоединить к домену,
если требуется контекст доменной учетной записи.
Рис. 3 Ярлык
гостевого приложения в меню основного компьютера.
Теперь
мы готовы к заключительному шагу — установке приложения в гостевую ОС.
Это можно сделать как вручную, так и используя решение развертывания
приложений. Установленное для работы в режиме совместимости с Windows XP
гостевое приложение можно запустить автоматически из меню «Пуск»
основной машины (рис. 3).
Чтобы использовать
интеграцию запуска, перед запуском гостевой виртуальной машины из меню
Пуск основного компьютера нужно выйти из системы гостевой виртуальной
машины и закрыть ее. Есть другой вариант: пользователи могут работать с
полным рабочим столом гостевой виртуальной машины, щелкнув ссылку с
отметкой Windows XP Mode. Если гостевая виртуальная машина не
используется, она переходит в спящий режим, что сокращает время
повторного ее запуска, когда она понадобится снова.
Как видите,
режим совместимости с Windows XP действительно предоставляет
виртуализацию на рабочем столе, а также ОС внутри другой ОС. Он также
предоставляет механизм, полностью избавляющий от сложностей
совместимости за счет предоставления поддерживаемой операционной
системы. Хотя число инструментов администрирования режима совместимости с
Windows XP ограничено, а требования к оборудованию довольно высоки, это
решение все-таки позволяет устранить препятствия на пути к обновлению
ОС. Только не забывайте, что это лишь один из вариантов решения ваших
проблем.
