Je l'ai fait à titre expérimental sur un vieil ordinateur de bureau équipé de Win7 et d'Office 2010. L'inconvénient majeur de ce script est le temps d'exécution : un peu plus de deux heures même si ce PC (i3) avait un SSD. Le gain était d'environ 9 Go d'espace disque grâce à tous ces correctifs intermédiaires d'Office supprimés... mais le script a créé 20 Go de logs en temp, donc ce n'est pas très pratique si vous manquez d'espace. (J'ai fait en sorte que le script sorte dans un journal également : il a supprimé environ 700 correctifs).
Je n'ai remarqué aucun effet négatif : aucune nouvelle mise à jour n'est proposée si vous vérifiez les mises à jour après avoir exécuté le script, donc il ne supprime rien d'essentiel et Office fonctionne toujours et peut être entretenu (ajouter/supprimer des composants fonctionne).
Réponse quelque peu théorique : si les MSP sont bien conçus, rien ne devrait se briser juste en exécutant ce script, à moins que vous ne désinstalliez ultérieurement les correctifs (soit manuellement, soit par un processus automatisé), auquel cas vous découvrirez si les correctifs étaient bien conçus.
Comme Heath (MSFT) explique Si vous supprimez les correctifs remplacés, il se peut que si le "correctif supérieur" est également supprimé manuellement, vous vous retrouvez avec une version de l'application beaucoup plus ancienne (et boguée) que prévu. Et je pense qu'en combinaison avec la fonctionnalité selon laquelle certains paquets remplacés peuvent être non désinstallables/"permanents", cela pourrait casser certaines applications ; passez deux paragraphes pour savoir comment cela pourrait se produire. ( permanent
est le mot-clé utilisé dans le .mum
archivo .)
Mais avant d'en arriver à ce scénario, laissez-moi clarifier quelque chose (qui est un bon moyen de voir ce qui se passe) : les correctifs remplacés, bien qu'ils soient toujours présents dans le registre (c'est ainsi que ce script les trouve) ne sont pas du tout affichés (au moins sur Win 7) dans les mises à jour installées, à moins qu'ils ne soient également pas marqués comme non désinstallables/. (J'ai testé cela moi-même, en modifiant ce script pour ne rien supprimer, mais juste lister ce qu'il ferait, puis en vérifiant les correctifs dans le Panneau de configuration). Mais si vous désinstallez un correctif supérieur, ce qui fait qu'un correctif remplacé mais désinstallable devient non dispersé, il réapparaîtra dans cette liste du Panneau de configuration, lorsque vous l'actualiserez. (Les auteurs de certains jeux d'outils wix tiers J'ai trouvé ce comportement assez déroutant .)
De plus, la suppression des correctifs remplacés ne doit pas être confondue avec msizap g
qui supprime les correctifs orphelins présents dans le répertoire mais non référencés dans le registre (du tout). Ce dernier est nécessaire parfois aussi lorsque certaines applications "spamment" des correctifs qu'elles n'enregistrent même pas du tout (VS 2005 était apparemment célèbre pour cela).
Mais il existe en fait un moyen de casser une application avec des correctifs mal conçus en désinstallant les correctifs intermédiaires/supérieurs : disons que vous avez des fichiers A et B, initialement tous deux à la version 1.0. Le correctif X met le fichier A à la version 1.1, ce qui est compatible avec le fichier B à la version 1.0. Puis le patch Y met le fichier B à la version 1.1, qui est également compatible avec A à la version 1.1, mais incompatible avec A à la version 1.0. Mais d'une manière ou d'une autre, ce patch Y est rendu non désinstallable, ce qui peut se produire dans les cas suivants d'un grand nombre de façons . Après ça, il y a le patch Z qui met les fichiers A et B à 1.2. Puis quelqu'un exécute le script qui désinstalle le patch X (remplacé), mais ne peut pas désinstaller Y (remplacé mais non désinstallable). Ensuite, il annule manuellement le patch Z, laissant exposés les fichiers A version 1.0 et B version 1.1 (du patch Y). Et cela casse l'application.
Certes, ce genre de scénario ne se produit probablement pas avec les applications MSFT pour lesquelles ils donnent une liste des MSP (correctifs) les plus récents qui peuvent être installés sans danger, c'est-à-dire sans que tous les MSP ancêtres soient installés. MS fait cela Par exemple, pour Office 2016 mais pas pour 2010 (bien qu'ils aient même pris la peine de faire une version cliquable de 2010). Et d'après mes vérifications rapides avec le script, Silverlight accorde (beaucoup) de correctifs non désinstallables (le script les appelle "permanents") mais remplacés, donc de telles choses existent même dans le royaume de MS. En fait, Office 2010 en a quelques-uns aussi, par exemple :
Microsoft Office Proof (Chinese (Traditional)) 2010 : Security Update for Microsoft Office 2010 (KB2760781) 64-Bit Edition is a permanent patch, run this script with /f to uninstall it
Et Adobe Acrobat Reader DC se comporte aussi à peu près comme Silverlight, avec de nombreux correctifs non désinstallables et dépassés.
Un document MS assez ancien, datant de l'époque de Vista, mérite également d'être signalé. a déclaré que le fait d'enlever les trucs remplacés de %windir%\Installer
est un condition préalable à une suppression sûre de SxS (ce qui est une autre source de ballonnement) :
La seule façon de réduire en toute sécurité la taille du dossier WinSxS est de réduire l'ensemble des actions possibles que le système peut entreprendre - la façon la plus simple de le faire est de supprimer les paquets qui ont installé les composants en premier lieu. Pour ce faire, vous pouvez la désinstallation des versions dépassées des paquets présents sur votre système . Le Service Pack 1 contient un binaire appelé VSP1CLN.EXE, un outil qui rendra le Service Pack permanent (non amovible) sur votre système et supprimera les versions RTM de tous les composants remplacés. Cela ne peut être fait que parce qu'en rendant le Service Pack permanent, nous pouvons garantir que nous n'aurons jamais besoin des versions RTM.
Donc, retirer les éléments remplacés de %windir%\Installer
devrait également aider à réduire la taille des SxS. Notez qu'il y a des méthodes semi-automatiques qui font la dernière chose (après qu'un patch remplacé soit réellement désinstallé, en utilisant l'API, pas une simple suppression, je suppose) :
-
dans Win 7 SP1 une méthode a été introduite vers 2013 avec kb2852386 qui ajoute un nouveau plugin de nettoyage de disque (app). Mais cela ne désinstalle pas les MSP liés à l'application de l'application. %windir%\Installer
par lui-même, je l'ai testé. Ce plugin enregistre ses actes dans %SystemRoot%\Logs\CBS\DeepClean.log
. Vous pouvez y voir des choses comme :
Package_for_RollupFix~31bf3856ad364e35~amd64~~7601.23642.1.0 superseded - uninstalled
2020-07-03 06:47:01, Info CBS
-
Dans Win 10 il y a dism /Cleanup-Image /StartComponentCleanup /ResetBase
qui semble transformer chaque patch non remplacé en un "service pack" désinstallable, selon sa documentation. En fait, la documentation de ce dernier suggère qu'il pourrait aussi désinstaller des patchs remplacés, mais je n'ai pas vraiment testé ce qu'il fait. Les revendications de MS :
Windows 10 et Windows Server 2016 réduisent automatiquement la taille du dossier WinSxS en utilisant des méthodes similaires à celles décrites dans cette rubrique, en plus des éléments suivants . des processus internes, tels que la désinstallation et la suppression de paquets dont les composants ont été remplacés par d'autres composants de versions plus récentes . Les versions précédentes de certains composants sont conservées sur le système pendant un certain temps, ce qui vous permet de faire marche arrière si nécessaire. Après un certain temps, ces anciens composants sont automatiquement supprimés de l'installation. [...]
L'utilisation du paramètre /StartComponentCleanup de Dism.exe sur une version en cours d'exécution de Windows 10 vous donne des résultats similaires à l'exécution de la tâche StartComponentCleanup dans le planificateur de tâches, sauf que les versions précédentes des composants mis à jour seront immédiatement supprimées (sans période de grâce de 30 jours) et que vous n'aurez pas de limite de temps d'une heure. [...]
L'utilisation du commutateur /ResetBase avec le paramètre /StartComponentCleanup de DISM.exe sur une version en cours d'exécution de Windows 10 supprime toutes les versions remplacées de chaque composant du magasin de composants. [...] Tous les Service Packs et mises à jour existants ne peuvent pas être désinstallés après l'exécution de cette commande. Cela ne bloquera pas la désinstallation des futurs Service Packs ou mises à jour.
Également intéressant, quelqu'un d'autre sur ce même forum MDL écrit un équivalent de /ResetBase pour Win 7 . Je ne l'ai pas testé. Ce dernier hack semble beaucoup plus compliqué que le simple script mentionné par l'OP. Il est également "livré" avec un complément complet d'outils de gestion de l'environnement. dismcore.dll
& etc. d'une (désormais) ancienne version de Win 7, donc je suis sûr qu'il fonctionne bien avec les piles de service ultérieures.
0 votes
Oui, l'inconvénient est que chaque fois que quelque chose se corrompt et que Windows Installer demande un MSI particulier, vous pourriez ne pas l'avoir. D'autre part, si vous effectuez des sauvegardes régulières, vous ne rencontrerez peut-être jamais une telle situation.
0 votes
Vous ne pouvez pas non plus désinstaller d'élément supprimé de là. Cela fait un moment, mais je crois préférer cet outil pour nettoyer les MSIs qui ne sont plus nécessaires : homedev.com.au/free/patchcleaner
0 votes
Si un problème était survenu avec ce script, cela aurait été évident dans ce fil de discussion des membres. Il semble qu'ils suppriment correctement les correctifs et sans conséquences.
0 votes
@0xC0000022L: ce script ne supprime que les fichiers msp, en utilisant l'API MS, qui comporte des vérifications approfondies pour savoir quel correctif est désinstallable.
dism /Cleanup-image /StartComponentCleanup
(introduit dans Win 10 si je me souviens bien) est probablement assez similaire. La seule chose qui n'est pas très claire dans la documentation de MS, c'est ce que signifie "status = 2", c'est-à-dire obsolète en réalité. Un correctif mal rédigé pourrait le définir mais ne pas être réellement entièrement obsolète, autant que je puisse en juger.0 votes
docs.microsoft.com/fr-fr/windows-hardware/manufacture/desktop/… "Windows 10 et Windows Server 2016 réduisent automatiquement la taille du dossier WinSxS en utilisant des méthodes similaires à celles décrites dans ce sujet, en plus des processus internes, tels que la désinstallation et la suppression de packages avec des composants qui ont été remplacés par d'autres composants avec des versions plus récentes."
0 votes
@Fizz si vous avez créé vos propres MSIs, que ce soit avec WiX ou avec un autre outil, vous saurez qu'il y a beaucoup de fois où - pour aucune raison apparente - l'Installateur Windows demande une source d'installation. Vous avez raison, les MSP sont moins problématiques, mais il y a des cas particuliers où ils peuvent être nécessaires. Et alors la question est de savoir si vous pouvez les fournir quand c'est nécessaire ou non.
0 votes
La question est que "supprimé" ne semble pas faire grand-chose stackoverflow.com/questions/19664040/…
0 votes
@Fizz WinSxS (Windows côte à côte) est une tout autre histoire, pourquoi mélangez-vous ces sujets?
0 votes
Oui, mais le nettoyage SxS n'est pas la seule tâche de Win 10 ; voir ci-dessus "en plus des processus internes, tels que la désinstallation et la suppression de packages dont les composants ont été remplacés par d'autres composants avec des versions plus récentes." Il faut admettre que ce n'est pas très clair ce que cela signifie/fait.
0 votes
@Fizz l'auteur de ce Q&A ne fournit pas suffisamment d'informations en fait. Nous aurions besoin de savoir des informations telles que le code produit et le code de mise à jour ainsi que si les versions ont réellement changé dans les ressources DLL (parce que c'est ainsi que fonctionne Windows Installer). Il n'est donc absolument pas clair dans ce Q&A que ce "ne fonctionne pas" est causé par Windows Installer par opposition à l'auteur et à la manière dont le MSP/MSI a été rédigé.
0 votes
Mais en ce qui concerne les MSP et la demande de source, s'ils sont désinstallés, il ne se peut pas que Windows demande une source pour eux plus tard. Mais il est tout à fait possible que l'application se casse. Heath (de MSFT) a donné une réponse quelque peu plus claire sur ce que signifie superseded... qui est essentiellement rien.
0 votes
@Fizz s'ils sont en effet désinstallés, vous avez parfaitement raison! Cependant, Microsoft a retiré un outil qui était censé être utilisable à cette fin (une partie de MS Office si je me souviens bien), car il ne nettoyait pas de manière fiable que ce qui n'était pas installé. De plus, installé a des nuances dans MSI, par exemple "annoncé" ... enfin, l'essentiel de l'histoire étant que si MS ne peut pas le faire correctement, sachant tout sur les entrailles de l'Installateur Windows, pourquoi voudriez-vous faire confiance à un script tiers pour le faire correctement?
0 votes
Eh bien au moins pour leur suite Office, MS ose fournir une liste de MSP à installer, qui ne sont pas tous les MSP qu'ils ont jamais publiés pour cette suite, ce qui signifie qu'au moins pour leurs MSP bien écrits, la prise en charge semble fonctionner correctement docs.microsoft.com/en-us/officeupdates/msp-files-office-2016