Aujourd’hui mon blog va porter sur l’erreur WINRM : 2144108387 0x8033809D que l’on peut retrouver sur tout les serveurs de :                                                                                                                                 - Windows 2003 SP2 à Windows 2012 R2. Même en regardant dans l’observateur d’évènement ID 4 qui correspond à une solution TechNet qui n’est pas adapter à la situation.

PERIMETRE: Dans le cadre de l’organisation des reboots de 400 serveurs chez un de nos client, j’ai mis en place une vérification Post-démarrage de ces 400 serveurs.

Voici la commande du script powershell qui permet de vérifier la date les derniers redémarrage des serveurs, bien sûr l’exemple ci-dessous porte sur 1 serveur le but étant de démontrer l’erreur winrm.

SCRIPT:

$computer = "SRV01"   
$LastBootUpTime = ([Management.ManagementDateTimeConverter]::ToDateTime((Get-WmiObject Win32_OperatingSystem).LastBootUpTime)).ToString("dd'/'MM'/'yyyy-HH'h'mm")

Invoke-Command -ScriptBlock { $LastBootUpTime }  -ComputerName $computer

RESULTAT:

ACTIVATION WINRM:

Bien évidement tout ceci est conditionné par le fait qu’il faille activer winrm sur tout les serveurs et que le port 5985 doit être ouvert lui aussi (invoke-command est utilisé, il lance la commande à distance .

sur certains serveurs, j’ai rencontré des problèmes lié à l’activation de WINRM dont l’un des serveurs SRV01.

ERREUR :

IDENTIFICATION DE L’ERREUR :  Apparemment lorsque le rôle serveur WEB est mis en place sur un serveur, il se peut que le TRANSPORT HTTP soit lié à un compte de service web exemple : SVC- WEB

Comment déterminer si un  compte de service est  attribué au service HTTP avec la commande exemple :                                                                       

setspn –q */srv01 

                                                                                                                                Une liste s’affiche ci-dessous : nous voyons clairement en violet que le service http est lié au compte de service web :  SVC- WEB

Checking domain DC=domaine,DC=com

CN= SVC- WEB,OU=Utilisateur,OU=Ordinateurs,DC=domaine,DC=com

      HTTP/SRV01

       HTTP/SRV01.domaine.com

TERMSRV/SRV01

       TERMSRV/SRV01.domaine.com

       WSMAN/SRV01.domaine.com

       RestrictedKrbHost/SRV01.domaine.com

       HOST/ SRV01.domaine.com

       WSMAN/SRV01

       RestrictedKrbHost/SRV01

       HOST/SRV01

Existing SPN found!

RESOLUTION : 

à savoir que cela puisse ne pas être une solution car il faut déterminer si les SITES WEB s’appuie sur un compte de service web et si ce compte ne gère pas d’autre site web qui s’appuie dessus , alors la solution appliquer ne permettra plus d’effectuer sous IE une requête sur:

 http://SRV01:80 ou http://SRV01:443                                                                                                                                                            Par contre si avez mis en place un cluster NLB site web exemple : http/clustersrv01-02.domaine.com, alors la solution peut être envisager

La commande permettant de ne plus lier le service http au compte de service WEB (SVC-WEB) est la suivante :

- Setspn   –D  http://srv01  SVC-WEB

- Setspn   –D  http://srv01.domaine.com SVC-WEB

Lorsque vous effectuer de nouveau la commande query :  setspn -q */srv01 nous voyons de nouveau  qui est lié au compte d’ordinateur  et plus au compte de service WEB si vous effectuer de nouveau  WINRM QC cela fonctionnera.

Checking domain DC=domaine,DC=com

CN= SRV01,OU=server,OU=Ordinateurs,DC=domaine,DC=com

TERMSRV/SRV01

       TERMSRV/SRV01.domaine.com

       WSMAN/SRV01.domaine.com

       RestrictedKrbHost/SRV01.domaine.com

       HOST/ SRV01.domaine.com

       WSMAN/SRV01

       RestrictedKrbHost/SRV01

       HOST/SRV01

Existing SPN found!

Introduction

Dans le cadre d'une infrastructure Orchestrator 2012 R2 en haute disponibilité, il est nécessaire de créer une ou plusieurs VIP pour les services web de ce produit. Pour rappel, ils sont au nombre de deux :

• Le web service, accessible via le port 81 avec une url du type : http://nom_du_server:81/Orchestrator2012/Orchestrator.svc 
• La console web (en silverlight), accessible via le port 82 avec une url du type : http://nom_du_serveur:82/

Le sujet de la haute disponibilité n'est détaillé que pour le rôle runbook server d'Orchestrator. Concernant les services Web, il n'y a aucune documentation proposée par Microsoft à l'heure actuelle (20/11/2014).

Dans cet article, je ne détaillerai pas la création de la VIP qui n'a rien de particulier. Il s'agit plutôt de voir la configuration à réaliser sur les serveurs Orchestrator portant les services web.

Au niveau des pré requis, il est donc nécessaire d'avoir au moins deux serveurs Orchestrator répondant aux services web cités précédemment.

Erreur rencontrée

Après avoir configurée une VIP, lorsque l'on essaie d'accéder au web service, cela ne pose aucun problème. Cependant ce n'est pas le cas de la console web.

Configuration

Afin de rendre opérationnelle notre VIP pour la console web Orchestrator, il faut réaliser une série d’opération sur IIS qu’il conviendra d’exécuter une ou plusieurs fois. En voici une liste récapitulative :

• Configuration du pool d’application : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).
• Ajout de SPN sur le compte de service Orchestrator : A réaliser une fois (via une invite de commande).
• Configuration des sites web pour l’utilisation des informations d’authentification du compte de service du pool d’application : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).
• Implémentation de l’url utilisée par la console web pour accéder aux web services : A réaliser sur le site console web Orchestrator sur tous les serveurs (nœuds) le proposant (via IIS Manager).
• Redémarrage des sites web Orchestrator : A réaliser sur les deux sites web (console web et web services) sur tous les serveurs (nœuds) les proposant (via IIS Manager).

Configuration du pool d’application :

Tout d’abord, il faut se rendre dans la console IIS Manager. Par défaut, Orchestrator utilise le pool d’application par défaut alors qu’il en crée un nommé System Center 2012 Orchestrator Web Features qui est défini avec le compte de service Orchestrator. Les deux sites web doivent donc être configurés pour utiliser ce pool d’application. Pour ce faire, on sélectionne le site web Microsoft System center 2012 Orchestrator Web Service, on clique sur Advanced Settings puis on parcours la liste des pools d’application disponibles,

Il suffit ensuite de sélectionner le pool System Center 2012 Orchestrator Web Features et de valider.

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des nœuds Orchestrator portant ces sites.

Ajout des SPNs nécessaires :

La seconde étape est l’ajout des SPN liés aux URLs utilisés pour accéder à la console web et aux web services Orchestrator au compte de service Orchestrator. Voici la liste des commandes à lancer pour ajouter les SPNs nécessaires (à noter vipihm et vipwebsvc peuvent être identiques si vous n’utilisez qu’une seule VIP pour la console web et pour les web services) :

SetSPN.exe –A HTTP/sco1 DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco1.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco2 DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/sco2.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipihm.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipwebsvc.myenterprise.com DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipihm DOMAIN\SERVICE_ACCOUNT
SetSPN.exe –A HTTP/vipwebsvc DOMAIN\SERVICE_ACCOUNT

Attention : N’oublier de remplacer sco1, sco2, vipihm et vipwebsvc par les valeurs de vos noeuds Orchestrator et de vos VIPs. DOMAIN\SERVICE_ACCOUNT doit être remplacé par votre compte de service.

NB : Cette opération n’est à réaliser qu’une seule fois.

Utilisation des informations d’authentification du compte de service du pool d’application :

Nous devons ensuite définir l’utilisation des informations d’authentification du compte de service du pool d’application sur les différents sites web. On sélectionne l’un des sites web Orchestrator dans IIS Manager puis on choisit Configuration Editor : Il faut parcourir l’arborescence jusqu’au niveau : system.webServer, security, authentication, windowsAuthentication.

Enfin, la propriété useAppPoolCredentials doit être défini à la valeur True.

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des noeuds Orchestrator portant ces sites.

Définir l’url utilisée par la console web pour accéder aux web services :

La dernière étape consiste à définir l’url utilisée par la console Orchestrator pour accéder aux web services. Dans IIS Manager, il faut sélectionner le site web Microsoft System center 2012 Orchestrator Orchestration console et cliquer sur Application Settings.

La valeur de l’attribut ScoServiceUri doit être changée avec la valeur de la vip : http://nom_vip:81/Orchestrator2012/Orchestrator.svc

Attention, si comme moi, vous décider d'effectuer un transfert de port (81 vers 80), alors il faudra supprimer ce dernier de l'URL : http://nom_vip/Orchestrator2012/Orchestrator.svc"

NB : L’opération ci-dessus est à réaliser pour le site Microsoft System center 2012 Orchestrator Orchestration console sur la totalité des nœuds Orchestrator portant ces sites.

Redémarrage des sites web :

 

NB : L’opération ci-dessus est à réaliser pour les deux sites web (Microsoft System center 2012 Orchestrator Web Service, Microsoft System center 2012 Orchestrator Orchestration console) sur la totalité des nœuds Orchestrator portant ces sites.

Une fois l'opération effectuée, la VIP est opérationnelle.

A titre informatif, l'environnement sur lequel la configuration a été testée était composé d'un HLB F5 possédant une VIP avec transfert de port 81 vers 80 pour le web services et une autre VIP pour la console Silverlight (port 82 vers 80). Cependant, cette configuration est valable quelque soit l'environnement.

Contexte

Ce billet fait suite à mon premier post sur l’option GEO des boitiers KEMP. Dans le billet précèdent j’expliquai comment faire pour contourner l’impossibilité de mettre des emplacements personnalisées sur les boitiers KEMP.

Hors depuis la version 7-1-20a, l’option GEO possède une nouvelle fonctionnalité : le Custom Location !

Mise en place

Avant la mise en place des custom location, il est intéressant de mettre à jour la base de données des localisations. Pour se faire connectez-vous au site https://support.kemptechnologies.com puis dans la partie Downloads et Other Downloads téléchargez la dernière version.

Connectez-vous à l’interface web du KEMP puis dans la partie Global Balancing, cliquez sur Miscellaneous Params. Dans Location Data Update cliquez sur Parcourir… sélectionnez le fichier d’update et cliquez sur Install Update.

Un message vous avertit une fois la mise à jour terminée.

Pour créer une Custom Location vous devez dans un premier temps indiquez une IP (ou un range d’IP). Pour cela dans la partie Global Balancing, allez dans IP Range Selection Criteria et ajoutez une IP en cliquant sur Add IP.

Indiquez l’IP (suivi du /32) ou un range d’IP (suivi de son masque sous la forme /XX) et cliquez sur Add Address.

Un message apparait pour valider l’ajout.

Cliquez ensuite sur Modify puis cochez la case Add Custom Location.

Indiquez un nom à la localisation puis sélectionnez-la dans la liste déroulante.

Cliquez sur <- Back pour valider et revenir à la page précédente.

Ce range d’IP appartient désormais à la localisation Siege – Noisy.

Il est désormais possible d’affecter cette localisation à une IP dans la partie Manage FQDNs.

Qu’est-ce que l’option GEO

L’option GEO des boitiers KEMP permet d'effectuer un équilibrage de charges multi-sites (sites internationaux). Cette option est conçue gérer un équilibrage de requêtes entre plusieurs datacenter en fonction de l’adresse IP publique du serveur DNS émetteur de la requête. Ainsi un utilisateur qui se trouve en France sera basculé vers les serveurs du site Français et un utilisateur qui se trouve aux Etats-Unis sera basculé sur les serveurs du site Américain.

L’option GEO fonctionne via le DNS. Les boitiers possédant l’option GEO deviennent des “serveurs DNS” autoritaire sur un FQDN (exemple : kemp.piservices.fr). Lorsqu’un utilisateur veux accéder à kemp.piservices.fr son serveur DNS le renverra vers un des boitiers GEO (au hasard, comme le veut le fonctionnement classique du DNS). Le boitier GEO récupère la position géographique du serveur DNS et lui indiquera le site le plus proche où se connecter.

Retour d’expérience

L’utilisation de l’option GEO peut également être utilisé dans un scénario LAN (en plus de son usage « traditionnel »). Dans ce cas les avantages sont :

• La possibilité d’avoir un système de load balacing Actif / Actif (impossible à réaliser chez Kemp sans l’option GEO)
• La possibilité d’équilibrer les requêtes provenant de certains sites distants sur un HLB en particulier avec fail-over vers un autre HLB (sous réserve que chaque site distant dispose de son propre DNS)

La mise en place de cette option sur les boitiers KEMP est rapide. Tout d’abord l’ajout du FQDN.

Ensuite l’ajout des adresses IP correspondantes au FQDN avec le choix des localisations.

Enfin il est nécessaire de faire une délégation DNS sur le FQDN.

L’option GEO possède néanmoins une limite, il est en effet impossible de créer des localisations personnalisées (exemple : plusieurs villes d’un même pays). Il est tout du moins possible d’ajouter des adresses IP (des serveurs DNS) à des pays. Avec cette méthode il est alors possible d’affiner la localisation à des villes ou des sites plus rapproché géographiquement.

Contexte

Les boitiers KEMP sont des Appliances de load-balancing. Ces boitiers permettent de répartir la charge des flux entrants.

La mise à jour de ces boitiers s’effectue en plusieurs étapes. L’opération de mise à jour sur deux boitiers (en mode High Availability) prend entre 15 minutes et 30 minutes.

Remarque : La mise à jour de boitiers KEMP implique une légère interruption de service.

Récupérer la mise à jour

Afin de récupérer une mise à jour KEMP il faut contacter l’éditeur via le formulaire suivant :

http://kemptechnologies.com/en/load-balancing-support/contact-support

Sauvegarde de la configuration

Avant de mettre à jour les boitiers, il est important de sauvegarder la configuration actuelle. Il sera ainsi rapide de remettre en place la configuration en cas d’échec de la mise à jour.

Pour se faire, se connecter à la shared IP et se rendre dans la partie System Configuration puis System Administration et enfin Backup / Restore. Cliquer sur Create Backup File. Le navigateur va alors télécharger le fichier de sauvegarde.

Sauvegarde des certificats

Il est important de sauvegarder également les certificats en place sur les boitiers.

Depuis l’interface d’administration (sur la Shared IP), aller dans la partie Certificates, Backup / Restore Certs. Insérer un mot de passe puis cliquer sur Create Backup File.

Mise à jours des boitiers

La mise à jour se fera ici sur deux boitiers KEMP en HA.

La mise à jour s’effectue dans un premier sur le boitier actif, puis sur le boitier passif (qui sera alors en mode actif).

Depuis l’interface d’administration (sur la Shared IP), aller dans System Configuration, System Administration, Update Software. Cliquer sur Browse…

Récupérer le fichier de mise à jour. Cliquer sur Update Machine pour lancer la mise à jour.

Un message informe que l’opération peut prendre du temps, cliquer sur OK pour passer à l’étape suivante. Le fichier est alors transféré vers le boitier.

Une fois le fichier transféré, une confirmation est demandée, cliquer sur OK.

La mise à jour s’installe puis un reboot est demandé. Ce reboot ne concerne que le boitier actif. Il y aura, à ce moment, une petite interruption du service le temps que le boitier passif prenne le relais.

A ce moment de la mise à jour, le boitier est indisponible comme le montre les deux icônes.

Une fois l’icône redevenu vert, se connecter sur l’adresse IP du boitier pour vérifier que tout fonctionne correctement.

Remarque : Il est préférable de vider la cache du navigateur afin de ne pas voir de fausses informations. Pour cela depuis les options internet, dans l’onglet General, cliquer sur Delete… puis cocher les cases Temporary Internet files, Cookies et History.

Une fois connecté sur le boitier mis à jour, vérifier que la version est bien celle voulue.

Refaire les mêmes actions une seconde fois pour mettre à jour le deuxième boitier. Le boitier premier boitier redeviendra ainsi l’actif.

Une fois les deux boitiers mis à jour, depuis l’interface d’administration (sur la Shared IP), vérifier la version.

Problématique

Lors du déploiement d’une nouvelle infrastructure Lync Server 2013 (sur un socle Windows Server 2012), le problème suivant peut apparaître sur les clients Lync :

Can’t sign in to Lync
We’re having trouble connecting to the server. If this continue, please contact your support team.

En lançant une analyse du composant SIPStack sur les serveurs front-End Lync via les outils Lync Server Diagnostic Tool et Snooper pendant la connexion d’un client, on observe l’erreur suivante :

0x80090331 SEC_E_ALGORITHM_MISMATCH

Remarque : Dans Lync Server 2013, l’outil de logging n’est plus intégré au déploiement. Pour l’installer, il faut déployer le pack d’outil Lync Server 2013 Debugging Tools disponible à l’adresse suivante : http://www.microsoft.com/en-us/download/details.aspx?id=35453

Explication

L’erreur SEC_E_ALGORITHM_MISMATCH se produit durant la phase de négociation du protocole TLS (le flux client –> serveur étant sécurisé en SIP over TLS).

Il semble que le service Lync Server Front-End ou bien le client Lync 2013 ne gère pas correctement les certificats signés numériquement en SHA512.

Résolution

Dans ce cas la résolution a consisté à déployer sur les serveurs Lync 2013 front-end un nouveau certificat signé avec les algorithmes SHA1/RSA en remplacement de l’ancien certificat signé en SHA512/RSA.

Ce comportement est assez étrange car le protocole SHA512 est intégré au système depuis Windows Vista pour les postes de travail et Windows Server 2008 pour les serveurs.

Les fichiers de réponses permettant d’automatiser l’assistant mini-installation post-SYSPREP doivent être créés avec l’outil Windows System Image Manager.

Cet outil est l’un des composants du kit WADK (pour Windows Assessment and Deployment Kit). Le kit WADK de Windows 8 est disponible en téléchargement à l’adresse suivante :

http://www.microsoft.com/en-us/download/details.aspx?id=30652

Durant l’installation, il faut sélectionner à minima le composant Deployment Tools pour que la console Windows System Image Manager soit disponible.

Une fois le kit installé, il faut lancer la console Windows System Image Manager, puis créer un nouveau fichier de réponse dans la section Answer file de la console.

Le fichier de réponse est composé de 7 sections correspondant chacune à une étape distincte du processus d’installation. Dans le cas d’un fichier de réponse destiné à automatiser l’installation du système (partitionnement, choix de la version du système…) la majorité des paramètres se configurent dans la section 1 windowsPE.

Dans notre cas (création d’un fichier de réponse destiné à automatiser la phase post-SYSPREP), la majorité des paramètres se configurent dans les étapes  4 (specialize) et 7 (oobe System).

Dans la section Windows Image de la console il faut aller sélectionner le fichier install.wim présent dans le répertoire Sources du média d’installation de Windows Server 2012.

Attention : Vous devez extraire les sources de Windows Server 2012 dans un dossier stocké sur un disque dur (la création des fichiers de catalogue ne pouvant être réalisée que sur un support en lecture / écriture)

Choisissez ensuite l’édition de Windows Server 2012 correspondant au système d’exploitation dont vous souhaitez automatiser le SYSPREP (dans cet exemple il s’agit d’une installation FULL de Windows Server 2012 Standard).

Une fois l’image sélectionnée, la phase de génération des fichiers de catalogue se lance. Attention cette phase peut être longue (environ 2 minutes sur un SSD mais jusqu’à 10/15 minutes sur un disque dur mécanique 5400 tours.min ou 7200 tours.min).

Une fois les fichiers de catalogue généré, l’ensemble des packages inclut dans le média doivent s’afficher dans la section Windows Image. Chaque package contient un ou plusieurs paramètres pouvant être configuré. Chaque package possède son propre périmètre d’application (certains s’appliquent à la phase 1 du déploiement uniquement, d’autres aux phases 3 et 4, etc…).

Pour ajouter un package (dans notre exemple il s’agit du package nommé amd64_Microsoft-Windows-IE-ESC_10.0.9200.16384_neutral qui permet de configuré les options de mode de sécurité renforcé Internet Explorer), il faut faire un clic droit, puis choisir dans quelle étape on souhaite intégrer les paramètres (dans notre exemple ce package s’applique uniquement à la phase 4 Specialize.

Une fois le package ajouté, il apparaît ensuite dans la section Answer File avec tous ses paramètres (ici le package dispose de deux paramètres). Une liste déroulante est disponible pour configurer chaque paramètre.

En passant les paramètres IEHardenAdmin et IEHardenUser à la valeur False, le mode de sécurité renforcé d’Internet Explorer sera désactivé durant la phase de SYSPREP.

La difficulté dans ce processus consiste à identifier tous les packages les plus intéressant pour réaliser une configuration automatisée de Windows Server 2012.

Le tableau ci-dessous énumère les paramètres les plus intéressants pour un déploiement standard. Les paramètres obligatoires pour automatiser le déploiement sont indiqués en bleu dans le tableau.

Les paramètres indiqués en vert sont optionnels mais peuvent être intéressant pour optimiser le déploiement (par exemple fixer une page par défaut dans le navigateur ou ne pas charger au logon la console Server Manager).

Au final vous devez obtenir un fichier de réponse proche de celui ci-dessous.

Le fichier de réponse peut ensuite être utilisé. Pour cela il faut le copier dans le répertoire C:\Windows\System32\SYSPREP, puis utiliser la ligne de commande suivante lorsque vous exécuterez la commande SYSPREP :

sysprep.exe /generalize /oobe /shutdown /unattend:"C:\Windows\System32\sysprep\monfichier.xml"

Avec ce fichier de réponse l’ordinateur / le master doit pouvoir démarrer après le sysprep sans qu’aucun paramètre ne soit demandé (aucune action entre le moment où le master est déployé et le moment où l’écran de logon s’affiche).

Rappels

Depuis la sortie de Windows Vista / Windows Server 2008, l’ensemble des composants Windows sont hébergés dans le répertoire C:\Windows\WinSXS.

Cela permet de pouvoir déployer l’ensemble des composants Windows Server (DNS, DHCP, Desktop Experience…) sans jamais avoir recours au média d’installation (DVD, clé USB…).

En revanche, le dossier WinSXS occupe beaucoup de place (entre 5 et 15 Go) et a tendance à occuper de plus en plus de volume avec le temps.

Cela s’explique facilement car ce dossier conserve une copie des anciennes versions des fichiers (.dll, .inf, .exe…) lorsqu’un service pack, mais aussi lorsqu’une simple mise à jour est déployée.

La conservation des anciennes versions des fichiers permet de revenir à l’état antérieur en cas de désinstallation du service pack ou bien de la mise à jour.

Dans certains scénarii, notamment lorsqu’un disque SSD de petite capacité est installé, il peut être nécessaire de réduire la taille du dossier afin de regagner de l’espace.

Optimisation du dossier

Pour réduire la taille du dossier WinSXS il est possible de supprimer les fichiers système antérieurs à l’application d’un service pack avec la commande suivante :

dism.exe /online /cleanup-image /spsuperseded

Cette commande existait déjà sous Windows 7 / Windows Server 2008 R2. Néanmoins dans Windows 8 / Windows Server 2012, il n’existe pas encore de Service Pack.

Windows 8 et Windows Server 2012 apportent une nouvelle option, nommée startcomponentcleanup, qui permet de retirer les anciennes versions de fichiers pour les composants Windows suite à l’application des simples mises à jour (patch KB). Voici la commande à saisir pour retirer ces anciens fichiers :

dism.exe /online /cleanup-image /startcomponentcleanup

Exécutée sur une nouvelle installation de Windows Server 2012 (sans aucun composant déployé mais avec l’ensemble des mises à jour au 12/07/2013), cette commande a permis de réduire la taille du dossier de 700 Mo environ (passage de 11.8 Go à 11.1 Go occupés sur le disque), soit un gain de 7% environ.

Il est possible d’aller encore plus en compressant le dossier, néanmoins cette action est non supportée (contrairement à l’usage de la commande dism.exe qui est une commande standard du système) et également fortement déconseillée dans le cas d’un serveur de production.

Pour ceux qui souhaitent optimiser un environnement de maquettage ou bien un poste de travail non critique, la compression permet tout de même un gain non négligeable (sur le même exemple il est possible de réduire la taille occupée sur le disque de 11.1 Go à 7.3 Go).

Pour réaliser la compression du dossier WinSXS (à vos risques et périls !), je vous conseille la procédure suivante qui a le mérite de faire revenir les ACL et l’attribut propriétaire à leur valeur d’origine en fin d’opération.

http://dandar3.blogspot.fr/2013/01/how-to-ntfs-compress-windows-winsxs.html

L’analyse de problème de performance d’un serveur, de performance d’une application client/serveur se fait par la mise en place de compteurs de performance.

L’analyse est souvent fastidieuse, quels compteurs mettre en place? interprétation des résultats? seuils d’alertes? etc..Bref souvent décourageant .

CODEPLEX fournit un outil qui permet d’interpréter ces résultats et de fournir un rapport.

Voici le lien pour le téléchargement et son installation:

http://pal.codeplex.com/

L’utilisation est assez simple.

Mettez en place toute une batterie de compteurs à analyser et collectez les informations pendant un temps donné.

Lancez l’outils:

Cliquez sur Next.

Sélectionnez votre fichier de log, puis cliquez sur Next.

Dans le menu Déroulant Threshold file title, sélectionnez l’application que vous souhaitez analyser, puis cliquez sur Next.

Répondez au questionnaire, puis cliquez sur Next.

Choisissez le temps de l’intervalle d’analyse. Cochez éventuellement “Process all…..”, puis cliquez sur Next.

Configurez le format de sortie, puis cliquez sur Next.

Cliquez sur Next.

Vous pouvez modifier la valeur “Threading” si vous le souhaitez. Cliquez sur Finish.

L’analyse est cours:

Et voilà:

Dans cette analyse aucune “alerte” n’a été détectée, signe de bonne santé du serveur

Bonne analyse.

Problème

Si vous essayez d’activer la découverte réseau sur un serveur Windows Server 2008 R2 vous n’y arrivez pas, la découverte est automatiquement désactivée dès que vous sortez de la page Modifier les options de partage pour d’autres profils réseau  

Résolution

La découverte du réseau et depuis la version Windows Vista utilise les 3 fournisseurs NetBIOS Provider, SSDP Provider et WS-Discovery (WSD) Provider qui ont été regroupés avec d’autres fournisseurs comme Registery Provider, PnP Provider et Third Party Providers dans une plateforme de découverte commune connu sous le nom de Function Discovery Plateform, cette plateforme fait appel aux services Windows suivants pour assurer ces fonctions :

• Computer Browser (Explorateur d’ordinateurs)
• SSDP Discovery (Découvert SSDP)
• UPnP Device Host (Hôte de périphériques UPnP)
• Registry
• Function Discovery Resource Publication (Publication de ressource de découverte de fonctions)
• Function Discovery Provider Host(Hôte du fournisseur de découverte de fonctions)
• Link-Layer Topology Mapper(Mappage de découverte de topologie de la couche de liaison)

Parmi les services cités il faudra s’assurer du démarrage des services :

• Function Discovery Resource Publication (Publication de ressource de découverte de fonctions)
• SSDP Discovery (Découvert SSDP)
• UPnP Device Host (Hôte de périphériques UPnP)

Pour que l’activation de la découverte du réseau puisse fonctionner correctement.