次の方法で共有

Немного о Windows Serviceability и ветвях обслуживания

  • [アーティクル]

Данная заметка не связана с виртуализацией. Сегодня хотелось бы поговорить о базовых принципах сервисного обслуживания в Windows - о том, как Microsoft нумерует свои обновления, как они устанавливаются на систему, как заменяют друг друга. Описав базовые принципы, мне станет проще оперативно рассказывать о выходящих обновлениях и исправлениях к операционным системам. Вся информация, представленная в этой заметке, основана на открытых источниках, в первую очередь на серии «Занимательная Нумерология» личного блога Артёма, а также на статье блога Пола Адамса.

Файлы, пакеты и номера версий

Очевидно, что минимальной единицей обслуживания в любом программном продукте является файл. Файлы группируются в пакеты. Из пакетов собираются Роли и Компоненты ОС. Давайте для начала разберёмся с версиями пакетов и файлов ОС Windows. Если взять любой файл, например hvix64.exe, то в его свойствах можно увидеть версию. Для Windows Server 2008 R2 с установленным первым пакетом обновления версия практически всех файлов будет 6.1.7601.17514. Здесь 6.1 указывает на ОС поколения Windows 7/R2, 7601 говорит о том, что версия на основе Service Pack 1, а 17514 есть номер сборки конкретного файла (в данном случае совпадающий с номером сборки самого пакета обновлений). То есть об ОС, где старшая версия файла hvix64.exe равна 6.1.7601.17514, можно сказать, что в ней установлен первый пакет обновлений, и нет никаких установленных обновлений, обновляющих данный файл. Почему я сказал старшая версия? Дело в том, что начиная с Vista, в Windows все версии системных файлов хранятся в специальном хранилище, а установка новых версий создаёт новые папки с номером версии и сохраняет туда файлы. При этом начиная с Vista больше нет такого понятия времён Windows 2000/XP как «DLL Hell», когда разные версии приложений требовали разные версии системных библиотек и просто не могли работать вместе, поскольку в System32 была единая, пусть и наиболее свежая, версия библиотеки. Несколько лет назад я публиковал заметку «Версии Hyper-V», в которой предлагал нехитрый PowerShell скрипт, позволяющий быстро перечислить все версии того или иного системного файла, установленного в вашей системе.

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

Итак, давайте разбираться дальше с файлом hvix64.exe. Мы уже знаем версию этого файла. Если мы поищем hvix64.exe в папке Windows\winsxs и подпапках, то увидим, что все его версии (если их несколько) находятся в папках вида amd64_microsoft-hyper-v-drivers-hypervisor_31bf3856ad364e35_6.1.7601.17514_none_8e7758d07c24d1f8. Имя папки позволяет нам заключить, что файл hvix64.exe входит в пакет microsoft-hyper-v-drivers-hypervisor версии 6.1.7601.17514, и обновления именно этого пакета будут нам интересны в рассматриваемых примерах версий файла hivx64.exe.

Ветви обслуживания и их взаимосвязь

Теперь поговорим о ветвях обслуживания Windows. Что это такое? Почему ветвей несколько? Как понимать, что именно установлено в вашей системе?

Обновления, периодически выпускаемые Microsoft, условно делятся на две ветви.

  • GDR (General Distribution Release branch). Это ветвь, включающая в себя все критические обновления и обновления безопасности, широко протестированные и предназначенные для установки на все компьютеры. GDR обновления включают в себя исправления из всех предшествующих GDR обновлений (из всех, номер сборки которых меньше).
  • Обновления QFE (Quick Fix Engineering), или иначе говоря, LDR (Limited Distribution Release branch) Эта ветвь включает в себя исправления всех найденных ошибок и проблем с данным пакетом или файлом. LDR обновления выходят значительно чаще чем GDR. LDR обновления проходят существенно меньшее тестирование и не могут быть рекомендованы к установке в чисто профилактических целях. LDR всегда включают в себя исправления, внесённые в последнем GDR исправлении, а также все исправления из предшествующих по версии LDR исправлений.

Номер сборки для GDR и LDR обновлений разный. Для GDR после выхода пакета обновлений обычно резервируется порядка 4000 сборок, а начиная с какого-то номера сборки резервируются для LDR.

Рассмотрим это на примере для Windows 7/R2:

Версия

Продукт

Веха

Ветвь обслуживания

6.1.7600.16xxx

Windows 7/Server 2008 R2

RTM

GDR

6.1.7600.20xxx

Windows 7/Server 2008 R2

RTM

LDR

6.1.7601.17xxx

Windows 7 SP1/Server 2008 R2 SP1

SP1

GDR

6.1.7601.21xxx

Windows 7 SP1/Server 2008 R2 SP1

SP1

LDR

Когда публикуется новая статья базы знаний, содержащая обновление, то в информации всегда значится, является ли это обновление LDR или же имеет LDR и GDR версии. Действительно, когда выходит GDR обновление, оно не должно удалить исправления, ранее внесённые установленными LDR обновлениями, хотя и не включает их. Поэтому GDR обновления выходят в виде сразу двух файлов: GDR файла с обновлениями, рекомендованными к установке всем, и которые устанавливаются автоматически, а также LDR обновлением, включающим в себя этот текущий GDR, а также все предыдущие LDR. LDR файл из GDR обновления устанавливается на систему в том случае, если в системе уже присутствует LDR версия этого файла. То есть обновление только повышает версию.

Запутанно?

Давайте проиллюстрируем теорию на примере, приведённом Полом Адамсом.

Пусть в некий момент времени T1 выходит новая версия Windows. Например, Windows Vista. Через некоторое время выходит GDR обновление «A» в виде файлов GDR и LDR. На чистую систему будет автоматически установлена GDR версия обновления. Далее выходит статья базы знаний, описывающая специфическую проблему, которую можно исправить, заказав LDR исправление «B». Через некоторое время выходит очередное GDR обновление безопасности «C». Если на вашей системе не было установлено LDR обновления B, то при установке обновления C будет установлена GDR версия. Если же версия обновляемого файла существует в LDR варианте (например, вы установили обновление B), то при установке GDR обновления C будет выбрана его LDR версия, включающая в себя исправление B.

Далее в момент времени T2 выходит первый пакет обновлений. Он включает в себя все известные на момент его заморозки обновления - как GDR, так и LDR. Даже если у вас были установлены LDR обновления к RTM версии ОС, то при установке пакета обновлений вы получите GDR версии файлов версии SP1. Далее опять начинают выходить обновления. Причём согласно правилам поддержки Microsoft во время жизненного цикла продукта обновления выходят как к последней вехе (в данном случае SP1), так и к предыдущей. И логика LDR/GDR тут та же самая. Далее выйдет второй пакет обновлений в момент Т3, и ситуация повторится. В момент времени Т4 закончится жизненный цикл поддержки продукта, и все исправления станут выходить только для последней вехи и только GDR. В данный момент это происходит уже с Windows Server 2003, а скоро настанет черёд и Windows Server 2008. Замечу, что некоторые обновления могут исправлять специфические изменения, внесённые в последнем пакете обновлений, и не выпускаться для предыдущей вехи.

Теперь от теории перейдет к практику и рассмотрим в качестве примера обновление 2517329

Обновление 2517329 является GDR обновлением для пакета microsoft-hyper-v-drivers-hypervisor, добавляющее поддержку процессоров Sandy Bridge и Westmere. Я описывал его в отдельной заметке, так что при желании можно почитать. Итак, данное обновление выпущено в следующих версиях:

Версия

Продукт

Веха

Ветвь обслуживания

6.1.7600.16792

Windows Server 2008 R2

RTM

GDR

6.1.7600.20941

Windows Server 2008 R2

RTM

LDR

6.1.7601.17592

Windows Server 2008 R2 SP1

SP1

GDR

6.1.7601.21701

Windows Server 2008 R2 SP1

SP1

LDR

Если у вас была установлена чистая система Windows Server 2008 R2, то файл hvix64.exe обновится до RTM GDR версии 6.1.7600.16792. Если на RTM версии ОС были установлены какие-то LDR обновления, например, 974909, то будет установлена RTM LDR версия 6.1.7600.20941. На чистую систему с Windows Server 2008 R2 Service Pack 1 будет установлено SP1 GDR обновление версии 6.1.7601.17592, а если после установки SP1, вы устанавливали, например, LDR обновление 2263829, то получите версию 6.1.7601.21701.

Кумулятивность и объединение ветвей

Что можно сказать о кумулятивности обновлений? Включают ли новые исправления все предыдущие? Определённо да. Нужно ли устанавливать обновление X, если уже установлено более новое обновление Y? Если вы не собираетесь удалять обновление Y, и все файлы обновления X обновлены в Y, то устанавливать X смысла нет. В качестве последнего примера рассмотрим обновления 2526776 и 2550569.

Обновление 2526776 я описывал в заметке со списком всех хотфиксов. Вкратце, оно включает в себя единственный файл hvix64.exe версий 6.1.7600.20930 для RTM LDR и 6.1.7601.21689 для SP1 LDR. Установка этого обновления всегда заменяет текущую версию на LDR, и до установки следующего пакета обновлений единственным способом вернуться на GDR версию будет удаление этого обновления и всех последующих обновлений данного пакета, которые будут устанавливаться лишь в LDR. Установка 2526776 не отменяет необходимости установки 2517329, поскольку обновляет лишь один файл; тогда как GDR обновление 2517329 обновило все файлы пакета.

Обновление 2550569 является LDR обновлением, выпущенным лишь для вехи SP1 в версии 6.1.7601.21726. Без установленного первого пакета обновлений, вы не сможете применить 2550569. Данное обновление включает в себя все файлы пакета microsoft-hyper-v-drivers-hypervisor, так что заменяет и 2517329, и 2526776, и, к слову сказать, ещё пары обновлений, вышедших после первого пакета обновлений. Если вас устраивает работа LDR ветви, можно ставить только 2550569, не устанавливая предшествующие.

Вместо эпилога

Я попробовал максимально доступно описать теорию Windows Serviceability для того чтобы далее в более простом виде вести список выпускаемых обновлений к различным компонентам ОС, используемых в виртуализации. Надеюсь, несколько наглядных примеров помогут вам понять, как именно «печёт» свои обновления кухня Windows Service Engineering. Более подробно можно почитать в цикле статей Артёма «Занимательная Нумерология».

Comments

  • Anonymous
    January 01, 2003
    Опять же вопрос - сами разрабы могут или не могут апдейтить в каталог? Что мешает, если не могут? Было бы удобно, при вменяемом рсс с их стороны. Но... есть рабочий винапдейт - к чему велосипеды изобретать и ныкаться некоторым разрабам мимо него?

  • Anonymous
    January 01, 2003
    Ссылка работает За каталог отвечает отдельная команда, увы, его не просто пополнить. Если есть вопросы, готов попробовать ответить.

  • Anonymous
    January 01, 2003
    Вопросов больше не имею, все заданы здесь или по ссылке выше. Не отвечено на всё... ну да и ладно, всё на свете не осилить и простому админу с 5-10 продуктами МС и хелпдеском же их - в одном флаконе + много стороннего нечто. RSS от MS c выборкой был бы удобен в подобных (большинстве) случаев в средних/мелких компаниях, даже если WSUS установлен. P.S. С ссылкой - да, извиняюсь, просто таймаут из "подПитера" часто проходит прежде, чем она может открыться. Указывает как-бы на востребованность ресурса, наверное.

  • Anonymous
    January 01, 2003
    Если есть возможность как-то повлиять - хотелось бы что-то вроде RSS аггрегатора по апдейтам с выбором продуктов. Спасибо за статью, многое разъянилось, но многое осталось за кадром (политки обновления отдельных продуктов, того же ТМГ - social.technet.microsoft.com/.../014f744c-c326-4c9e-b501-5d72a0603332). Плюсанул намного раньше.

  • Anonymous
    January 01, 2003
    Ссылка на "Занимательный блог" Артема Проничкина устарела, мягко говоря. Все мы люди, все мы человеки...