La sortie de Windows Seven ne tarit pas vraiment le flot de questions sur le répertoire WinSxs, son utilitié et surtout sa taille…

Qu’est-ce que WinSxS?

WinSxS (SxS pour Side-By-Side soit côte-à-côte) est une technologie intégrée à Windows ainsi un emplacement de stockage centralisé pour les fichiers d’installation de Windows, des mises à jours et des application à conditions que celles-ci soient compatibles avec cette technologie.

Les buts de cette technologie sont les suivants:

• Améliorer voire garantir (grâce notamment à d’autres technologie connexe) l’intégrité du système, de ses dépendances et composants additionnels/optionnels
• Palier aux problèmes récurrents de conflits de DLL qui affectent Windows depuis des années.

Un garant de l’intégrité du système?

Windows Vista et à fortiori Seven sont des systèmes modulables, en tous cas, beaucoup plus modulables que XP et ses prédécesseurs. Lors de l’installation, tous les fichiers sont copiés sur le disque dur même si certains sont liés à des fonctionnalités non-activées. Cela évite que par après, à l’activation de celles-ci, on ne se retrouve avec des conflit de version si par exemple, un service pack a été installé entretemps.

Afin d’éviter les manipulations manuelles hasardeuses, les emplacements habituels du systèmes et des applications tels que “C:\Windows” ou “C:\Program Files” sont protégés par des permissions assez strictes qui empêche même l’administrateur ou le compte “SYSTEM” d’y effectuer des modifications de fichiers. Cela évite également toute modification par des processus malveillants même ci ceux-ci exploitent le contexte de sécurité d’un administrateur. Cette protection se voit renforcée grâce à l’UAC (User Account Control), encensé ou décrié, c’est selon…

Seul le compte “TrustedInstaller” (Installateur approuvé) possède les permissions suffisantes pour modifier les fichiers et répertoires stockés dans ces emplacements.. Ce compte est en fait un compte de service, principalement responsable de toutes les installations de mises à jour, service pack, fonctionnalités etc… Il est d’ailleurs propriétaire de la plupart de ces fichiers. Donc, à moins de modifier ces permissions (opération non supportée), aucun moyen modifier le contenu de ces répertoires, WinSxS inclus.

WinSxS, par la même occasion, permet également la désinstallation de Service Pack de manière propre et sans danger pour le système, pour peu que les fichiers originaux soient préservés (voir section “Et peut-on le nettoyer pour faire de la place?”)

La solution aux problèmes de conflits de DLL?

“Avant”, les applications ayant besoin d’un DLL donnée la recherche tout d’abord dans leur propre répertoire d’installation et faute de la trouver, cherchaient ensuite dans divers répertoires (les emplacements et ordre de priorité diffèrent selon la version de Windows et le paramétrage, voir MSDN - Dynamic-Link Library Search Order.

Des DLL bien connus et très utilisées comme comdlg32 ou le runtime C++ par exemple, se retrouvaient à divers endroits à divers niveaux de versions

Actuellement, et pour autant que l’application soit conforme à la technologie SxS, elle expose ses besoin en terme de DLL (et version) sous la forme d’un manifeste (fichier XML de configuration), contenant une liste de “dépendances”.

Pourquoi ce répertoire utilise-t-il autant d’espace disque?

Regardé par le biais d’un explorateur Windows, il semble en effet être un gouffre à Giga et c’est en grande partie le cas car il contient, en gros presque tous les fichiers nécessaires pour installer et maintenir Windows ainsi que les applications installées, à l’exception de celles antérieures à cette technologie bien entendu.

En réalité, beaucoup de fichiers présents dans les sous-répertoires de WinSxS sont des “hardlinks”: un lien de très bas niveau qui pointe vers le fichier réel et se comporte exactement comme lui. Impossible de reconnaitre un hardlink en utilisant la commande DIR ou l’explorateur. L’outil en ligne de commande “FSUTIL hardlink list” permet d’afficher ces hardlink pour un fichier donné mais pas de lister tous ceux présdent dans un répertoire donné. A ma connaissance, seul l’outil non MS “FINDDUPE” permet de lister ceux-ci, via l’option “-hardlink”, voir http://www.sentex.net/~mwandel/finddupe/.

Donc en résumé, l’espace disque utilisé en réalité en moindre que ce que représente le total de WinSxS et des autres répertoires car nombre de “doublons” donnent l’impression contraire. Note: la taille réelle d’un hardlink est en fait négligeable.

Et peut-on le “nettoyer” pour faire de la place?

Malgré ce que certains clament haut et fort dans les forums, il n’existe aucun moyen pour réduire de manière drastique la taille de ce répertoire, qui rappelons-le est moins volumineux que ce que l’Explorateur Windows ou la command DIR pourrait indiquer. Il faut égalemnt garder à l’esprit qu’il ne fera que grandir étant donné les MAJ du système et des applications. En attendant, on peut réduire sa taille de manière modérée par les méthodes suivantes:

• Désinstaller proprement les applications inutiles. Note: retirer des fonctionnalités Windows de réduira en rien sa taille
• Si la désinstallation “propre” s’avère impossible, tenez à l’aides des utilitaires MS suivants: Windows Installer CleanUp et l’Outil de nettoyage d'inscription de correctifs
• Retirer les fichiers liés au Service Pack, au risque toutefois de ne plus pouvour désinstaller ledit service pack. Cela se fait à l’aide des commandes VSP1CLN.exe (Service Pack 1, voir http://technet.microsoft.com/en-us/library/cc709655%28WS.10%29.aspx) et COMPCLN.exe (à partir su service pack 2)

Question subsidiaire: peut-on déplacer ce répertoire?

Pas à ma connaissance!

Est-il nécessaire d’en prendre un backup

Non, ce répertoire est lié au système et applications installées, pas au données des utilisateurs.

Par contre, il rend également le système quasi parfaitement compatible au backup de type “Image”: Winimage, Acronis… Parce que, notamment, il prévient les dépendant sur les sources d’installation externes…

Infos Complémentaires

• MSDN - Windows Resource Protection
• MSDN - Application Installing and Servicing

Marc

Une petite surprise de fin d’année 2009 repointe le bout de son nez début 2010: Sur IIS6, si un site est paramétré pour utiliser l’authentification Windows Intégrée (IWA), le processus W3WP.exe servant ce site est susceptible de planter avec le code de retour 0xffffffff si Windows Server 2003 est en service pack 2 et que la mise à jour KB973917 est installée.

Ce problème est en fait causé par un certain nombre de fichiers d’IIS qui ne sont pas au niveau requis malgré la présence du service pack 2.

Petite procédure pour remettre IIS en ordre de marche et si nécessaire réinstaller cette MAJ

1. Effectuer un inventaire des MAJ actuellement installées, afin de pouvoir les réinstaller si nécessaire par après. Personnellement j’utilise PsInfo pour ce faire (option –h). Mais il existe évidemment d’autres méthodes
2. Ré-appliquer le Service Pack 2
3. Si nécessaire, réinstaller les MAJ en fonction de l’inventaire effectué à l’étape 1
4. Vérifier les niveaux de version des fichiers d’IIS. Voir “Complément d’information”
5. Si nécessaire, réinstaller la MAJ KB973917

Complément d’information

• MS KB: Il est possible qu'Internet Information Services 6.0 ne fonctionne pas correctement après l'installation de KB973917
• MS KB: Description de la mise à jour qui implémente la protection étendue pour l'authentification dans les Services IIS
• MS Security Research & Defense Blog: Extended Protection for Authentication
• MS TechNet: Microsoft Security Advisory (974926) Credential Relaying Attacks on Integrated Windows Authentication
• Blog du Team Support IIS US: VBScript permettant de vérifier les niveau de version de fichiers d’IIS
• Version PowerShell du VBScript mentionné ci-dessus que j’ai adapté librement. Attention: les deux scripts semblent de pas récupérer les niveaux de version correctement sur les plateformes 64-bit, à investiguer donc!

Evidemment, il se peut que IIS plante pour d’autres raisons. Le code de retour devrait dans ce cas vous mettre sur la piste du coupable.

Marc

A plusieurs reprises, il m'a été donné d'aider des administrateurs ou développeurs SharePoint aux prises avec ce comportement pour le moins déconcertant: alors que les utilisateurs peuvent se connecter et s'authentifier au serveur SharePoint sans le moindre problème, les administrateurs ayant ouvert une session localement sur le serveur se voient refusés l'accès à SharePoint tout en recevant l'erreur HTTP 401.1 (Unauthorized: Access is denied).

Ce comportement est, comme souvent avec Microsoft "By Design" depuis le service pack 1 de Windows Server 2003: il a pour but d'augmenter le niveau de sécurité sur un serveur lorsque les conditions suivantes sont d'application:

• La version de l'OS est au moins Windows Server 2003 SP1
• Un utilisateur ou administrateur est loggé localement sur la console du serveur ou via RDP
• Il (ou elle, ne soyons pas macho, le système ne l’étant pas), tente d’accéder à une ressource ou un service utilisant l’authentification NTLM en passant un nom d’hôte pointant vers l’adresse de loopback (127.0.0.1) alors que ce nom d’hôte n’est pas “localhost”

Le résultat étant un “Access Denied” ou en langage HTTP, un 401.1. il est à noter que ce problème pourrait tout aussi bien se produire en accédant à un répertoire partagé, par ex.

Bien mais pourquoi est-ce alors si flagrant dans le cas  de SharePoint? Il existe deux grands cas de figure dans lesquels il est fréquent de recourir à la modification du fichier HOSTS afin de faire pointer une ou plusieurs application web vers l’adresse 127.0.0.1:

• L'indexeur paramétré pour se viser lui-même, et non un autre serveur frontal. Cela se faisant soit manuellement par l’édition du fichier HOSTS, soit en laissant SharePoint s’en charger
• Les machines de développement, afin d’éviter de devoir enregistrer des noms dans le serveur DNS

Il n’est pas rare que des scripts de “warm-up” de SharePoint provoque également le problème.

Plusieurs solutions existent:

• Désactiver complètement cette fonctionnalité, voir l’article de KB suivant: Message d'erreur en utilisant le nom de domaine complet ou l'alias CNAME d'un serveur pour y accéder localement après l'installation de Windows Server 2003 Service Pack 1 : « Accès refusé » ou « Aucun logiciel réseau n'a accepté le chemin réseau fourni »
• Déclarer les noms par lesquels le service sera accédé, voir le même article de KB ci-dessus
• Utiliser Kerberos plutôt que NTLM. Kerberos inclut son propre système de vérification des noms par lequel le service est accédé (Service Principal Name)

Marc

La consolidation est à la mode, Exchange n'y échappe pas. Moins de serveurs donc plus de BALs sur le même serveur. Idem pour les contrôleurs de domaine AD.

Récemment, un client en pleine phase de consolidation m'a fait part d'un problème d'authentification impactant uniquement les utilisateur d’Outlook et ce de manière récurrente: “aléatoirement”, les utilisateurs reçoivent une boîte de dialogue émanant d’Outlook leur demandant de se ré-authentifier. Les administrateurs Messagerie ayant tôt fait de décréter qu’il s’agissait d’un problème AD, l’équipe en charge dudit AD a commencé à chercher les problèmes d’ouvertures de session, de comptes verrouillés etc… Mais rien de visible au niveau des contrôleurs de domaine: pas de “logon failed”, de mot de passe expiré, en tout cas pas pour les utilisateurs subissant ce désagrément. Plus étrange encore, ce sont les utilisateurs d’un même site qui se plaignent, mais les utilisateurs impactés sont différents chaque jour (!).

Décision fut prise de prendre une trace réseau à partir du contrôleur de domaine dédicacé à ce site et également utilisé pour les opérations MAPI/NSPI. Verdict: le DC retourne à certains clients le message “MAPI_E_LOGON_FAILED” alors que l’utilisateur est bel et bien authentifié avec certitude. Après investigation, le coupable est une nouvelle option de sécurité au niveau AD qui limite le nombre de connections MAPI/NSPI concurrentes à 50 (par défaut) sur les DC tournant sous Server 2008 et retourne donc l’erreur MAPI_E_LOGON_FAILED à Outlook. Celui-ci l’interprétant correctement cad en demandant de saisir nom d’utilisateur et mot de passe à nouveau.

Fort heureusement, il est possible d’augmenter cette limite de conncetions voire de revenir au comportment d’application sur les versions antéreures de Windows (2000-2003). L’article du support MS ci-dessous fournit les explications, la solution ainsi que le niveau de logging à configurer pour qu’un événement soit écrit de le log de Windows dès que la limite est atteinte.

• MS KB - Connexions NSPI à partir de Microsoft Outlook à un contrôleur de domaine Windows Server 2008 risquent d'échouer avec un code d'erreur: « MAPI_E_LOGON_FAILED »

On aurait évidemment préféré que le protocole côté serveur retourne un message plus en rapport avec la cause exacte, dans le style “Too many concurrent connections” par ex…

Marc

Microsoft a récemment publié un outil à destination des organisations de taille petite à moyenne (Max 20 serveurs, 500 postes clients) afin de faciliter l’évaluation du niveau de qualité de l’infrastructure Microsoft qu’elles opèrent.

Cet outil, basé sur le moteur “Best Practice Analyzer (BPA)”, se concentre sur l’analyse des éléments-clés suivants:

• Etat des contrôleurs de domaine
• Réplication Active Directory et SYSVOL
• Synchronization du temps (NTP…)
• Résolution de noms (DNS)
• Le configuration réseau des serveurs en général (AD et Exchange)
• Des éléments de configuration Exchange fortement liés à AD (objets, connecteurs AD…)

Son installation et son éxécution nécéssitent bien évidemment des privilèges administratatifs sur toutes les machines à analyser. L’éxécution quant à elle est facile et centralisée, à partir de la machine connectée au domaine sur laquelle il est installé, les connections à distance se faisant grâce à WMI. Les OS à partir de Windows Server 2003 SP2 sont supporté. L’installation requiert le framework .NET 2.0.

En pratique, son éxécution prend la forme d’un assistant vous guidant pas à pas. Etant donné sa simplicité d’utilisation, je ne m’attarderai que sur les points les plus importants selon moi, soit les suivants.

L’outil ayant la faculté de se mettre à jour lors de chaque éxécution, il est impératif de décocher la case “Install available updates (recommended)” si la machine sur laquelle vous l’éxécutez n’est pas en mesure de se connecter à Internet. Il n’est pas inutile de mettre à jour le client Windows Update de la machine sur laquelle vous l’éxécuterez si vous comptez utiliser la fonctionalité de MAJ.

Au cours de la configuration, le terme “primary firewall” signifie en fait “passerelle par défault”, ce qui rejoint bien le type de réseau en place dans la plupart des infrastructures de type PME/PMO

Il est évident que pour permettre l’utilisation de WMI, les machines distantes doivent être configurées correctement au niveau de leur firewall (si applicable bien sur)

l’outil éxécutera tous les tests pour lequel il est prévu, je n’ai pas trouvé de moyen standard de spécifier de tests spécifiques (cela semble possible en bidouillant le fichier XML de configuration, ce que l’on ne recommandera pas évidemment). L’éxécution peut prendre du temps, en fonction de la complexité de l’infrastrcture, du nombre de serveurs, de l’état de ceux-ci voire des problèmes potentiellement rencontrés.

L’outil rapportera un status “Completed" si le test s’est bien passé OU si celui-ci n’est pas applicable (!). Cela peut créer un peu de confusion. Exemple: dans mon environnement de test, pas d’organisation Exchange présente, les tests Exchange passent pourtant tous au vert…

Si vous souhaitez conserver un rapport d’éxécution détaillé, il ne faut pas oublier de cliquer sur le bouton “Open larger view” ou récupérer le ficher XML correspondant sous C:\Microsoft IT Environment Health Scanner\Wizard\Data. Le bouton ”Open larger view” ouvrant en fait un Internet Explorer montrant le rapport au format XML présenté correctement (voir l’exemple ci-dessus concernant les tests Exchange)…

Visiblement, l’outil ne teste pas les trusts et encore moins les configurations à forêts multiples. Logique, vu son public-cible.

Il est également un peu “sensible” au niveau de la configuration DNS: zone intégrée à AD, délégation, glue records… Mais ce n’est pas plus mal pour garantir une infrastructure saine!

Conclusions

Suffisament complet et facile à utiliser, c’est un très bon outil pour les administrateurs de petites structures. Il peut être idéalement complété par l’Exchange Best Practices Analyzer si nécessaire.

• Lien de téléchargement, en version anglaise uniquement pour l’instant: MS Downloads - Microsoft IT Environment Health Scanner

Marc