PI Services

Contexte

Dans le cadre de projets, il peut arriver que les licences définitives ne soient pas livrées au moment du déploiement des serveurs. Pour ne pas perdre de temps, il est possible d’installer la version d’évaluation de Windows Server 2012 R2 (http://technet.microsoft.com/fr-fr/evalcenter/dn205286.aspx) qui est valable 180 jours et de la mettre à niveau vers une version commerciale une fois la licence acquise.

Solution

La commande-let DISM permet de mettre à niveau notre version d’évaluation vers une version commerciale (avec licence).

Pour se faire, lancez l’invite de commande en tant qu’administrateur et tapez la commande suivante :

DISM /Online /Set-Edition:<type de version> /ProductKey:<licence> /AcceptEula

Une fois la commande terminée, il faut redémarrer le serveur.

Remarque : Afin de savoir vers quelle type de version il est possible de mettre à niveau le serveur utilisez la commande DISM /Online /Get-TargetEditions

Après le redémarrage le serveur n’est plus un serveur d’évaluation et il peut être activé normalement.

Remarques

1 – Cette commande fonctionne également avec une des nouveautés de Windows Server 2012 R2 : l’AVMA (Automatic Virtual Machine Activation).

2 – Attention cette mise à niveau ne fonctionne pas si le serveur est un contrôleur de domaine. Pensez donc bien à faire la manipulation avant l’installation du rôle Active Directory Domain Services !

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

Symptôme

Suite au déploiement d’une architecture OCS 2007 R2 composée de plusieurs serveurs (typiquement un serveur front-end déployé dans le réseau local associé à un serveur Edge situé en DMZ), les erreurs suivantes peuvent se produire si l’un des serveurs ou les deux exécutent Windows Server 2008 R2 :

Voici le détail de chacune des deux erreurs :

Explication

Ces erreurs sont dues à un problème “connus” avec OCS 2007 R2 et Windows Server 2008 R2 autour de la fonction InitializeSecurityContext de la couche TLS.

Ces erreurs empêchent toute communication TLS entre les serveurs et entraînent donc des disfonctionnement au sein d’OCS (le protocole SIPs étant utilisé par défaut).

Résolution

Pour résoudre ces problèmes, il faut installer un correctif sur l’ensemble des serveurs OCS 2007 R2. Ce correctif est disponible sur demande à l’adresse suivante :

• http://support.microsoft.com/kb/975858/en-us

Suite à l’installation, les serveurs doivent être redémarrés.

Cette grosse faille de sécurité a été publiée par Microsoft le 16 juillet dernier ( CVE-2010-2568 ). Elle exploite le mode de fonctionnement des raccourcis ( ".LNK" ) sur tous les OS Windows. Bien sûr la mise à disposition du patch correspondant sera annoncée dans le bulletin de sécurité :http://www.microsoft.com/technet/security/advisory/2286198.mspx.

L’exploitation de cette faille se traduit par le fait, qu’un malware puisse s’exécuter par le biais du détournement du mécanisme d’affichage d’icône.

Cette vulnérabilité est exploitable localement par disque amovible ou via des partages réseaux et WebDAV

Il n'existe pas de correctif à ce jour. Mais en attendant des solutions de contournement recommandées par Microsoft peuvent-être mises en place.

La désactivation de l'affichage d'icône pour les raccourcis peu ainsi limiter les risques d’exploitation de cette faille. Cette solution affiche les icônes en blanc par défaut. Pour se faire il est nécessaire depuis l’éditeur de registre, de rechercher dans la ruche HKEY_CLASS_ROOT, IconHandler afin de modifier sa valeur par défaut par 0 après l’avoir exporté pour revenir à la valeur précédente dès la sortie d’une mise à jour.

Autre solution de contournement la désactivation du service WebClient se fait en passant par le gestionnaire de l’ordinateur ou en exécutant services.msc

Enfin troisième solution le blocage du téléchargement des fichiers LNK et PIF depuis Internet est recommandé. 

La liste des systèmes Windows concernés et supportés s'étend de Windows XP SP3 à Windows Serveur 2008R2.

Notez que des éditeurs d’antivirus (Sophos, Eset) ont déjà répertorié Stuxnet depuis mi-juillet exploitant cette vulnérabilité.

MAJ: Le 3 Aout Microsoft apporte une réponse par la mise en ligne de l'update KB2286198 annoncé dans le bulletin de sécurité suivant http://www.microsoft.com/technet/security/bulletin/MS10-046.mspx

Il vous est peut être déjà arrivé de devoir répondre à cette question.

Voici une commande DOS simple et rapide pour y répondre:

systeminfo | find /i "install date"