Patching
An application that has been installed using the Microsoft Windows Installer can be upgraded by reinstalling an updated installation package (.msi file), or by applying a Windows Installer patch (an .msp file) to the application.
A Windows Installer patch (.msp file) is a self-contained package that contains the updates to the application and describes which versions of the application can receive the patch. Patches contain at a minimum, two database transforms and can contain patch files that are stored in the cabinet file stream of the patch package. For more information about the parts of a Windows Installer patch package, see Patch Packages.
Servicing applications by delivering a Windows Installer patch, rather than a complete installation package for the updated product can have advantages. A patch can contain an entire file or only the file bits necessary to update part of the file. This can enable the user to download an upgrade patch that is much smaller than the installation package for the entire product. An update using a patch can preserve a user customization of the application through the upgrade.
**Windows Installer 4.5 and later:В В **
Beginning with Windows Installer 4.5, developers can mark components in a patch with the msidbComponentAttributesUninstallOnSupersedence value in the Component table. If a subsequent patch is installed, marked with the msidbPatchSequenceSupersedeEarlier value in its MsiPatchSequence table to supersede the first patch, Windows Installer 4.5 and later can unregister and uninstall components marked msidbComponentAttributesUninstallOnSupersedence to prevent leaving behind unused components on the computer. If the component is not marked with with this bit, installation of the superseding patch can leave an unused component on the computer. Setting the MSIUNINSTALLSUPERSEDEDCOMPONENTS property has the same effect as setting this bit for all components.
**Windows Installer 3.0 and later:В В **
Developers who use Windows Installer 3.0, and author patch packages that have the MsiPatchSequence table can create patch packages that do the following:
- Use the product baseline cached by the installer to more easily service applications with smaller delta patches. For more information about using the product baseline, see Reducing Patch Size.
- Skip actions associated with specific tables that are unmodified by the patch. This can significantly reduce the time required to install the patch. For more information about which tables can be skipped, see Patch Optimization.
- Create and install patches that can be uninstalled singly, and in any order, without having to uninstall and reinstall the entire application and other patches. For more information about uninstalling patches, see Removing Patches.
- Apply patches in a constant order regardless of the order that the patches are provided to the system. For more information about how the Windows Installer determines the sequence used to apply patches, see Sequencing Patches.
- Apply patches to an application that has been installed in a per-user-managed context. For more information, see Patching Per-User Managed Applications.
**Windows Installer 2.0:В В **
The MsiPatchSequence table is not supported. Beginning with Windows Installer 3.0, patch packages can contain information that describes the patching sequence for the patch relative to other updates and additional descriptive information.
The recommended method for creating a patch package is to use patch creation tools such as Msimsp.exe and Patchwiz.dll. Developers can generate a patch creation file as described in the section: Creating a Patch Package. The creation of a small update patch is described in the section: A Small Update Patching Example.
Microsoft Windows Installer accepts a Uniform Resource Locator (URL) as a valid source for a patch. For more information about how to install a patch located on a Web server, see Downloading and Installing a Patch From the Internet.
A single Windows Installer patch (.msp file) can be applied to the installation package when installing an application for the first time. For more information, see Patching Initial Installations.
It is not possible to eliminate all circumstances when the application of a patch may require access to the original installation source. However, to minimize the possibility that your patch will require access to the original source, adhere to the points listed in the following section: Preventing a Patch from Requiring Access to the Original Installation Source.
To minimize the possibility that your patch is not broken by a subsequent customization transform, typically the patch is installed first, followed by the customization. Installing customization transforms first, and then the patch, may break the customization. For more information about patching customized applications, see Patching Customized Applications.
Uninstallable Patches
Whether a patch can be uninstalled depends upon how the patch was authored, the version of Windows Installer used to install the patch, and the changes made by the patch to the application. If a patch is not uninstallable, then the only way to remove the patch is to uninstall the entire application and reinstall without applying the patch being removed.
You can call for the uninstallation of patches applied with Windows Installer version 3.0 by using Command Line Options, the MsiRemovePatches function, or the RemovePatches method as described in the Uninstalling Patches section. The Windows Installer verifies that each of the patches listed for removal in the MSIPATCHREMOVE property is uninstallable. If the user does not have privileges to remove the patch, the patch is unknown for the product, patch policy prevents removal, or the patch was marked as not uninstallable, the installer returns an error indicating a failed installation transaction.
Windows Installer 2.0: Not supported. Patches applied using a version of Windows Installer that is earlier than Windows Installer 3.0 are not uninstallable.
Patches that are Not Uninstallable
A patch (.msp file) applied to an installed application is not uninstallable in the following cases. The only method to remove a patch that is not uninstallable is to uninstall the patched application and then reinstall the application without reapplying the patch. In this case, you must reapply any patches that you do not wish to be removed from the application.
Patches applied using a version of Windows Installer that is less than Windows Installer 3.0 are not uninstallable.
Patches applied to applications installed on a computer that has had the DisablePatchUninstall policy set by an administrator are not uninstallable. When this machine policyhas been set, no patches on the computer can be uninstalled, even by an administrator.
Patches that do not have a MsiPatchMetadata table in their database are not uninstallable.
Patches that do not include the following row in their MsiPatchMetadata table are not uninstallable. The patch is not uninstallable for other values of Company, Property, and Value.
| Company | Property | Value |
|---|---|---|
| AllowRemoval | 1 |
The patch has been applied to an application installed in a context for which the user has insufficient privileges to uninstall patches. The words «Not Allowed» in the following table indicate that an administrator or non-administrator user cannot uninstall patches from patched applications installed in this context. The word «Allowed» in this table means that privileges do not prevent an administrator or non-administrator user from uninstalling patches, however for any of the other reasons discussed in this section, it still might not be possible to uninstall the patch.
| application Installation Context | Administrator Uninstall of Patch | Non-Administrator Uninstall of Patch |
|---|---|---|
| Per-Machine | Allowed | Generally Not Allowed The only exception is if the patch was applied using (LUA) patching. A patch marked as a LUA patch is uninstallable by either administrators or non-administrators. LUA patching is only available for packages installed per-machine from media and require special authoring. |
| Per-User Non-Managed for Current User | Allowed | Allowed |
| Per-User Non-Managed for Different User | Not Allowed | Not Allowed |
| Per-User Managed for Current User | Allowed | Not Allowed |
| Per-User Managed for Different User | Not Allowed | Not Allowed |
A major upgrade applied by a patch is not uninstallable. Major Upgrades of an application should be performed by installing the upgraded application (.msi file) rather than a patch.
Patches applied to an administrative installation are not uninstallable. Patching administrative installations is not recommended. The current set of patches should be applied on the user’s computer after the user installs the application from the administrative image. This can prevent the package code cached on the user’s computer from becoming different than the package code on the administrative installation. If the package code cached on the user’s computer becomes different from that on the administrative installation, reinstall the application from the administrative installation and then patch the client computer.
When a patch adds new content to any of the tables in the following list, Windows Installer marks the patch as being not uninstallable. An uninstallable patch can add new files, assemblies, registry entries, components, or features to an installation by adding new rows to database tables that are not included in this list.
Удаление обязательных обновлений
Название Удаление обязательных обновлений не до конца раскрывает смысл описываемого в статье, поскольку не совсем понятно, что именно имеется в вижу под термином «обязательный». Материал можно было бы озаглавить как удаление обновлений, которые не удаляются или удаление неудаляемых обновлений , но тогда не совсем понятно, по каким причинам они вдруг стали неудаляемыми: по воле разработчика или из-за ошибок с хранилищем компонентов. Есть еще вариант обозначить как удаление обновлений, не предназначенных для удаления, но это как-то избыточно, что ли.
Совсем недавно открыл для себя одну любопытную особенность некоторых обновлений: они не удаляются стандартными средствами операционной системы. На практике возникла ситуация, в которой я никак не мог удалить из системы «битое» обновление. По мере углубления в тематику вопроса выяснилось, что в Windows существуют разные типы обновлений, и что частный случай невозможности удаления некоторых из них вовсе не является следствием какой-либо локальной ошибки, а отражает скорее особенность. Судя по всему, объясняется это архитектурными нюансами механизма обновлений. На практике сложно создать такую систему взаимосвязей обновлений, в которой каждое обновление будет полностью автономно, то есть независимо от остальных, и, соответственно, может быть удалено без каких-либо последствий. Но еще более важно то, что некоторые обновления для системы действительно критичны, поскольку достаточно глубоко в неё интегрированы. Например сам механизм обновления (стек обслуживания) обеспечивается набором модулей (инсталлятор, библиотеки и прч), которые необходимы для установки последующих обновлений и от которых зависит работоспособность механизма в целом. Соответственно, все обновления стека обслуживания, вносящие алгоритмические изменения, не могут быть просто удалены, поскольку тогда станут недоступными некоторые особенности этих алгоритмов, при помощи которых уже были установлены последующие пакеты обновлений. Удаление подобных обновлений чревато для системы серьезными последствиями, такими как разрушение хранилища компонентов, и как следствие, потенциальные проблемы с работоспособностью самой операционной системы. На самом деле так уж всё страшно, поскольку подобных обязательных (неудаляемых) обновлений, например в системе Windows 7, насчитывается всего-то около десятка 🙂 Но знать то об этом нюансе все же стоит, так же как и иметь понимание, как именно производить удаление обязательных обновлений.
Проблема
С точки зрения технического специалиста, установка и удаление системных обновлений относятся к типу тривиальных задач. В наш век глобальной сети Интернет, обновления в систему устанавливаются постоянно, часто вовсе незаметно для пользователя. Обновления представляют собой исправления безопасности различных компонентов, модули, содержащие дополнительный функционал уже существующих приложений, а так же новое программное обеспечение. Однако, наряду с задачами установки обновлений, зачастую встают и задачи удаления системных обновлений. Причины на то могут быть совершенно разнообразными, начиная от необходимости банально переустановить какое-либо из обновлений для достижения корректной работоспособности и заканчивая необходимостью исправления проблем зависимостей и целостности хранилища компонентов.
Система предоставляет несколько способов удаления обновлений из системы, например через компонент Центр обновления Windows , апплет Установленные обновления . В этом случае пользователь просто выделяет щелчком левой копки мыши (маркирует) интересующее его обновление и по щелчку правой кнопки мыши открывает меню Удалить , либо выбирает одноименный пункт из верхней панели:
тут всё тривиально. Но с обязательными обновлениями всё несколько сложнее, поскольку при аналогичных действиях мы не видим привычных элементов управления:
при попытке выполнить удаление данного компонента из командной строки при помощи утилиты wusa :
wusa /uninstall /kb:2522422
выдается ошибка: Обновление для Microsoft Windows является обязательным компонентом для этого компьютера, поэтому удаление невозможно.
В этом случае у специалиста возникает резонный вопрос: за что вы так со мной? 🙂 Тот факт, что система считает некоторые обновления обязательными и не дает их удалять, вовсе не гарантирует, что эти обновления не могут повреждаться и являться причиной различного рода проблем. Поэтому, в некоторых случаях появляется необходимость удаления. Имеется ли возможность удалить подобные неудаляемые обновления из системы?
Решение
Поэтому действуйте крайне аккуратно, желательно сделав полный бэкап системы либо создав точку восстановления. Главное понимать, зачем Вы всё это делаете. Если Вам необходимо исправить последствия кривого обновления, то удалите обязательное обновление, а затем установите его вновь. При удачном раскладе после удаления/переустановки неудаляемого обновления Вам удастся исправить последствия кривого обновления, однако при худшем сценарии развития событий, Вы приведете систему в нерабочее состояние, поскольку обновление может оказаться ключевым. Итогом может стать повреждение хранилища компонентов с ошибкой STATUS_SXS_COMPONENT_STORE_CORRUPT .
На каком уровне обеспечивается неудаляемость подобных обязательных обновлений? На уровне параметров в конфигурационных .mum -файлах.
А где содержатся и откуда появляются в системе сами .mum -файлы? А они содержатся в .msu-файлах установки, которые приезжают в систему через Центр обновления Windows либо скачиваются и устанавливаются пользователем вручную в виде файлов с расширением .msu , например Windows6.1-KB2639308-x64.msu .
В .mum -файле есть параметр с именем permanence , принимающий два значения: removable и permanent . Пакеты обновления, которые не желательно удалять из системы, разработчики Microsoft объявляют как «постоянный» (permanent), тогда как все остальные (обычные) пакеты обновления маркируются как «удаляемые» (removable). Поэтому, процесс изменения типа обновления с неудаляемого на удаляемое сводится к изменению данного параметра в соответствующем .mum -файле.
