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 est corrompu et que Windows Installer vous demande un MSI particulier, il se peut que vous ne l'ayez pas. D'un autre côté, si vous effectuez des sauvegardes régulières, vous ne rencontrerez peut-être jamais une telle situation.
0 votes
Vous pouvez également ne pas désinstaller les éléments que vous retirez de là. Cela fait un moment, mais je crois que je préfère cet outil pour nettoyer les MSI qui ne sont plus nécessaires : homedev.com.au/free/patchcleaner
0 votes
S'il y avait un problème avec ce script, il aurait été évident dans ce fil de discussion des membres. Il semble qu'ils fassent le retrait du patch correctement et sans aucune conséquence.
0 votes
@0xC0000022L : ce script supprime uniquement les fichiers msp, en utilisant l'API de MS, qui a contrôles approfondis pour quel patch est impossible à distribuer.
dism /Cleanup-image /StartComponentCleanup
(introduit dans Win 10 IIRC) 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 "superseded". Un correctif mal écrit peut définir ce statut mais ne pas être complètement remplacé, pour autant que je puisse dire.0 votes
docs.microsoft.com/fr/us/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 cette rubrique, en plus des processus internes, tels que la désinstallation et la suppression des paquets 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 MSI, que ce soit dans WiX ou dans un autre outil, vous savez qu'il y a de nombreuses fois où - sans raison apparente - Windows Installer demande une source d'installation. Vous avez raison de dire que les MSP sont moins problématiques, mais il existe des cas limites où elles peuvent être nécessaires. La question est alors de savoir si vous êtes en mesure de la fournir quand elle est nécessaire ou non.
0 votes
Le problème est que "remplacé" ne semble pas faire grand-chose. stackoverflow.com/questions/19664040/
0 votes
@Fizz WinSxS (Windows side-by-side) est une toute autre histoire, pourquoi mélangez-vous ces sujets ?
0 votes
Oui, mais le nettoyage SxS n'est pas la seule chose que Win 10 fait ; voir ci-dessus "en plus des processus internes, tels que la désinstallation et la suppression des paquets avec des composants qui ont été remplacés par d'autres composants avec des versions plus récentes". Certes, ce n'est pas très clair ce que cela signifie/fait.
0 votes
@Fizz l'auteur de cette Q&R ne donne pas assez d'informations en fait. Nous aurions besoin de connaître des informations telles que le code produit et le code de mise à jour, ainsi que de savoir si les versions sont en fait modifié dans les ressources DLL (car c'est ainsi que fonctionne Windows Installer). Il n'est donc absolument pas clair, à partir de cette question-réponse, que ce "non-fonctionnement" est dû à Widnows Installer et non à l'auteur et à la manière dont le MSP/MSI a été créé.
0 votes
Mais en ce qui concerne les MSP et la demande de source, s'ils sont désinstallés, il est impossible 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 un peu plus claire. réponse sur ce que fait "superseded"... qui n'est rien en fait.
0 votes
@Fizz s'ils sont effectivement désinstallés, vous avez parfaitement raison ! Cependant, Microsoft a retiré un outil qui était censé être utilisable à cette fin (faisant partie de MS Office IIRC), parce qu'il n'a pas pas ne nettoie de manière fiable que les choses qui n'ont pas été installées. Aussi installé a des nuances dans MSI, par exemple "annoncé" ... de toute façon, l'essentiel de l'histoire étant que MS ne peut pas le faire correctement, sachant tout sur les rouages de Windows Installer, pourquoi voudriez-vous faire confiance à un script tiers pour le faire correctement ?
0 votes
Au moins pour leur suite Office, MS est assez audacieux pour fournir une liste de MSP à installer, qui ne sont pas tous les MSP qu'ils ont publiés pour cette suite, ce qui signifie qu'au moins pour leurs MSP bien rédigés, la substitution semble fonctionner correctement. docs.microsoft.com/fr/us/officeupdates/msp-files-office-2016