Il était une fois dans la technologie, il y a de nombreuses années, Microsoft a présenté un logiciel serveur en grande pompe lors d’une réunion de professionnels de l’informatique. L’entreprise a démontré à quel point il était facile d’utiliser le logiciel, qui installerait automatiquement le serveur, le serveur de messagerie et le serveur Sharepoint, le tout en moins de 30 minutes.

Il y avait un problème : chaque fois que Microsoft faisait une démonstration du logiciel serveur, il échouait avec un message d’erreur peu clair.

À l’époque, je postais parfois et répondais à des questions dans un groupe de discussion Microsoft. Juste avant Thanksgiving, j’ai commencé à voir des consultants essayant d’installer le logiciel voir le même échec. Une personne dans le fil de discussion a compris le problème : un fichier dll SharePoint spécifique utilisé lors de l’installation avait une date d’expiration le 23 novembre. Si vous avez installé le logiciel serveur avant cette date, vous n’avez eu aucun problème. Si vous essayez de le faire après, l’installation échouera. La solution de contournement ? Allez dans le bios du serveur, remettez la date avant le 23 novembre, installez le logiciel, puis remettez l’horloge à l’heure correcte.

Si vous savez quelque chose sur les contrôleurs de domaine Active Directory, vous savez que changer les dates et les heures n’est généralement pas judicieux. Heureusement, les serveurs n’ont subi aucun effet néfaste et, à part un œuf sur le visage pour une sortie de produit moins qu’idéale en Australie, Small Business Server 2003 a continué à être acclamé.

Pourquoi je relaie cette histoire maintenant? Parce que cela montre que les bogues de publication dans les nouvelles technologies ne sont pas nouveaux. Microsoft utilise un processus de fichiers de signature de code pour valider et vérifier que les fichiers sont légitimes. Si le certificat n’est pas valide ou a expiré, le système d’exploitation ou des fichiers spécifiques peuvent ne pas fonctionner. Et c’est pourquoi des rapports ont commencé à apparaître la semaine dernière à propos d’un certificat qui a expiré de manière inattendue, déclenchant des problèmes avec les applications dans Windows 11. (La société a publié un correctif pour corriger le problème vendredi ; plus d’informations à ce sujet ci-dessous.)

PC concernés exécutant Windows 11 Home ou Pro eu des problèmes avec les applications suivantes:

• Clavier tactile, saisie vocale et panneau Emoji ;
• Interface utilisateur de l’éditeur de méthode d’entrée (IME UI) ;
• Mise en route et conseils ;
• Outil de biopsie.

Les utilisateurs exécutant le mode Windows 11 S (une version d’accueil spécifique qui vous permet d’installer des logiciels uniquement à partir du Microsoft Store) peuvent également avoir rencontré des problèmes avec la page Comptes et la page de destination dans l’application Paramètres, puis dans le menu Démarrer.

Comme Matt Graeber a souligné sur Twitter: « La fonction MinCryptVerifyCertificateWithPolicy2 dans ci.dll renvoie STATUS_IMAGE_CERT_EXPIRED lorsqu’un fichier est prévisualisé et signé _et_ le certificat a expiré. »

En fin de compte, Microsoft a utilisé la version bêta, ou dans ce cas le code d’édition Insider, dans la version finale de Windows 11 – et le certificat sur le code a expiré le 31 octobre. Non seulement cela, mais le code a été signé par l’autorité de certification de développement Microsoft. Graeber a continué: « Là où je me sens plus à l’aise de spéculer maintenant, c’est que le fait de ne pas charger le code de construction de prévisualisation expiré est intentionnel afin de rendre le système d’exploitation inutilisable pour les utilisateurs qui tentent d’utiliser les versions de prévisualisation du système d’exploitation indéfiniment. »

La signature de code est importante. C’est l’une des raisons pour lesquelles Microsoft peut diviser les correctifs de sécurité en morceaux et utiliser des technologies telles que des techniques d’optimisation de la diffusion qui permettent de les diffuser directement depuis Microsoft ou depuis des ordinateurs partagés dans votre réseau peer-to-peer. Les pièces sont ensuite recombinées – et le code est validé pour s’assurer qu’il n’a pas été falsifié. Vous pouvez obtenir vos correctifs de n’importe où et la plate-forme confirmera toujours que le correctif que vous installez est un code Microsoft valide et qu’il n’a pas été falsifié.

Normalement, lorsque Microsoft publie un produit final, il supprime les certificats de développeur et les remplace par le processus de signature final.

Bien qu’il y ait eu un correctif de prévisualisation pour Windows 11 qui résolvait la plupart des problèmes, Microsoft a publié un correctif hors bande vendredi pour résoudre le problème. KB5008295 devrait « résoudre complètement un ensemble de problèmes affectant l’outil de capture, le clavier tactile, certaines applications intégrées et le mode S sur Windows 11 », le l’entreprise a déclaré sur Twitter.

Suite des informations détaillées sont disponibles ici.

À Askwoody.com nous utilisons le « processus MS-DEFCON » pour les recommandations de correctifs. À l’aide d’une échelle de un à cinq, nous informons les utilisateurs lorsqu’il est possible d’installer des mises à jour en toute sécurité. (Un 1 signifie qu’aucune mise à jour ne doit être installée ; un 5 signifie que tout est clair.) On m’a récemment demandé quand nous commencerions à inclure Windows 11 dans le système MS-DEFCON. Bien que je suive les mises à jour de Windows 11 parce qu’il est maintenant considéré comme un « produit publié », je considère toujours qu’il en est au début de la phase de test ; Je ne recommande pas qu’il soit installé sur les systèmes de production.

Bien que Windows 11 récupère de ce problème de signature de code, il indique toujours pourquoi le nouveau système d’exploitation de Microsoft ne doit être pris en compte que pour les tests. De toute évidence, Windows 11 a besoin d’un peu plus de temps pour résoudre les bogues.

La bonne nouvelle en cette ère de mises à jour Windows est que Microsoft n’a pas eu à fabriquer de nouveaux CD d’installation pour faire face à ce problème. C’était une solution assez rapide et facile. Mais je trouve toujours remarquable que même avec de nouveaux processus et procédures de développement de code au cours des deux dernières décennies, des bogues comme celui-ci surgissent toujours.