PI Services

Le blog des collaborateurs de PI Services

Réplication DFS-R & contraintes d’utilisation

Contexte

Lors de l’utilisation d’un partage réseau, les utilisateurs on souvent l’habitude de travailler directement sur les fichiers partagés.

Afin d’éviter toute corruption des données, un système de verrouillage est utilisé, il garantie que seul un unique utilisateur n’édite le fichier. Ce système fonctionne avec les fichiers temporaire/propriétaire.

Voici les étapes d’ouverture et d’enregistrement pour un fichier Word :

1. A l’ouverture du fichier, Word crée un fichier temporaire où les modifications seront enregistrés. Si un autre utilisateur tente de modifier le fichier, le message d’erreur suivant lui apparait :

Ce fichier est déjà ouvert par <nom_utilisateur>. Souhaitez-vous en faire une copie ?

2.  Lors de l’enregistrement du fichier, Word supprime la version d’origine, et la remplace par le fichier temporaire qu’il a renommé comme le fichier d’origine.

Ainsi, plusieurs utilisateurs auront accès au même fichier sans que celui-ci ne soit corrompu.

Contraintes en mode répliqué

Dans le cas d’un partage de fichiers répliqué, l’intégrité des fichiers n’est plus assurée.

Prenons le scénario suivant :

image

Dans ce cas de figure les utilisateurs sont redirigés depuis le namespace vers l’un des deux serveurs de données. En fonction de l’ordre “Refferal Ordering” qui par défaut dirige les clients entre les deux serveurs de manière égale.

Or si un utilisateur modifie le fichier work.docx sur le serveur FILE01, le serveur FILE02 n’en seras pas avisé (la fonction de verrouillage de fichier étant locale) et un autre utilisateur seras en mesure de modifier le même fichier causant une perte d’intégrité où le dernier fichier enregistré sera celui gardé par les deux serveurs.

Afin d’éviter ce type de comportement dangereux, il est possible de modifier le fonctionnement des deux serveurs, tout en gardant un minimum de répartition de charge.

Contournement

Imaginons que les serveurs FILE01 et FILE02 hébergent chacun deux fichiers répliqués indépendamment, Commerce et Administratif.

La première chose à faire est de forcer les clients à n’accéder qu’à un seul des deux serveurs, le serveur secondaire seras utilisé dans le cas où le premier venait à ne plus fonctionner.

Pour ce faire il faut dans la partie “Folder Targets” du namespace Commerce choisir le dossier hébergé par le serveur secondaire (FILE02), ouvrir la fenêtre des propriété puis choisir l’onglet “Advanced” et affecter à ce dossier la priorité “Last among all targets” :

image

Ainsi les utilisateurs souhaitant accéder au partage Commerce, seront toujours dirigé vers FILE01 en priorité.

On peut également aller plus loin et interdire la modification des fichiers sur l’un des serveurs le rendant membre “Read-Only”. La réplication ne fonctionneras alors que dans un sens et le serveur Read-Only, comme son nom l’indique ne pourras qu’afficher les fichiers hébergé en lecture seule.

Pour appliquer le Read-Only sur le serveur secondaire, choisir dans la partie “Replication” le lien de réplication, et dans l’onglet “Membership” sélectionner le serveur membre secondaire comme ceci :

image

Conclusion

A l’aide de ce contournement les utilisateurs Administratif utiliserons un serveurs tandis que les utilisateurs Commerciaux en utiliseront un autre.

Les deux serveurs sont malgré tout répliqués donc en cas de défaillance de l’un, l’autre pourras prendre le relais, cependant, il ne faut pas oublier – en cas de défaillance du serveur principal – de retirer l’option “Read-Only” si celle-ci a été mise en place.

Maintenance d’un DAG – Les bonnes pratiques

Introduction

Un groupe de disponibilité dans Exchange permet de répliquer les bases entre plusieurs serveurs Mailbox. L’idée générale est qu’il y ai toujours une base de montée (base active) pendant qu’une ou plusieurs bases passives – situées sur d’autres serveurs du DAG - répliquent les derniers changement afin d’être prêtes à prendre le relais si le serveur hébergeant la base active ne répondrait plus.

image
Exchange 2013 permet jusqu’à 50 bases (actives et passives) par serveur et limite à 16 le nombre de serveurs Mailbox par DAG.

Le schéma à gauche présente un DAG composé de trois serveurs se partageant trois bases différentes.

Les bases en vertes sont les bases actives, celles en gris les passives. On remarque qu’il n’y a toujours qu’une seule base d’active parmi les trois présentes.

Lorsqu’une base n’est plus disponible, le composant “Active Manager” détecte l’indisponibilité et sélectionne parmi les bases passives candidates la plus apte à prendre le relai (Best Copy Selection).

Utilité

Lors d’une maintenance sur un membre d’un DAG Exchange (Database Availability Group), quelques précautions sont à prendre.

Or pourquoi prendre la peine d’exécuter les scripts de maintenance lorsque le rôle du DAG est justement de permettre la perte d’un ou plusieurs serveurs sans que les bases hébergées ne soient impactées ?

Bien que le DAG prévoit tout pour éviter la perte de données, la perte de données n’est pas impossible. En cas de problème, l’administrateur peut se voir obligé d’accepter une perte de données pour remonter les bases en échec…

Scripts & Explications

Après avoir vu les dangers d’une bascule ratée, comment préparer une maintenance sur un membre du DAG et comment faire face à une mauvaise réplication.

Etape 1 :

Sur le serveur à redémarrer exécuter la commande Powershell suivante :

C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\StartDagServerMaintenance.ps1 –serverName MAIL01

Le serveur MAIL01 n’héberge plus de base active et peut maintenant être redémarré.

Etape 2 :

C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\StopDagServerMaintenance.ps1 -serverName MAIL01

Cette commande va réactiver ce nœud du DAG le rendant “apte” à héberger des bases actives.

Etape 3 :

C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\RedistributeActiveDatabases.ps1 –DagName DAG -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution -Confirm:$false

Ce dernier script à appliquer permet d’équilibrer les bases actives sur les membres du DAG.

Symantec Endpoint Protection Manager – Reset Password

Problématique

Si il vous arrive d’oublier votre mot de passe utilisé pour l’accès à la console Symantec Endpoint Manager, il peut être bien pratique de rétablir les identifiants par défaut.

De plus, l’accès à la console SEP Manager est sécurisé par un système qui bloque pour une durée de temps variable l’authentification dès que plusieurs authentifications ont échouées.

Procédure

  • Tout d’abords vérifier que les services utilisé par SEP sont bien lancé, si ce n’est pas le cas, les démarrer puis retenter l’authentification,
  • Ouvrir un explorateur de fichier,
          • Se placer dans C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Tools
          • Exécuter en tant qu’administrateur le script Resetpass.bat
          • Les identifiants ont étés remis par défaut soit : admin/admin
          • Le log scm-server-0.log situé dans C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Tomcat\Logs enregistre tout les évènements d’échec d’authentification, pratique pour troobleshooter un problème. 

Template VHD pour HYPER-V

Lors de la mise au point d’une maquette sur un poste portable, il est pratique d’avoir en local des templates au format VHD. Dans ce post nous verrons comment créer des templates au format VHD ainsi que comment les déployer à l’aide d’HYPER-V.

Créer un template au format VHD

Tout d’abords il faut créer une machine virtuelle avec l’OS désiré pour le template, il est également pertinent de passer les derniers patchs ainsi que d’installer la dernière version des services d’intégrations HYPER-V. Il est également possible d’installer des applications qui seront utiles au master.

    • Un fois la VM prête pour être transformée en template, il serait judicieux d’éteindre la VM et d’en copier le VHD (avant l’exécution du sysprep) afin de pouvoir recréer le Template si celui-ci venait à être mis à jour.
    • Après avoir démarré la VM, il faut maintenant exécuter le sysprep sur celle ci en prenant bien soir de cocher la case generalize afin de générer un nouvel SSID lors de l’utilisation du template.

image

  • Une fois la VM éteinte, il faut en copier le VHD vers l’emplacement souhaité, il est par ailleurs préférable d’ ajouter l’attribut Read-Only au VHD généré.

Utiliser un template VHD dans HYPER-V

En utilisant HYPER-V, il est très simple de déployer un OS à l’aide d’un VHD, pour ce faire il suffit de suivre l’assistant de création d’une machine virtuelle et une fois arrivé à la page Connect Virtual Hard Disk il faut utiliser un VHD existant et ne pas laisser HYPER-V en créer un automatiquement :

image

Utiliser MDT/WDS – Partie 1

Introduction

Windows Deployment Services (WDS) est la solution proposée par Microsoft pour le déploiement de master via réseau. En soit WDS ne s’occupe que de la partie déploiement du master brut, pour aller plus loin, c’est vers MDT qu’il faut se diriger.

Microsoft Deployment Toolkit ajoute à WDS la possibilité de créer des séquences de tâche, l’intérêt de cette fonction est d’ajouter au master déployé par WDS drivers, applications et personnalisations..

Dans ce 1er post nous verrons comment créer une image de capture et capturer une image de Windows à laquelle nous aurons ajouté les dernières mises à jour, nous n’utiliserons donc que WDS.

Le post suivant se concentrera sur MDT et la création de “Task Sequences”.

Prérequis

Pour ce tutoriel nous utiliseront les prérequis suivants :

        1. Les sources de l’OS à préparer,
      1. Un poste physique ou une VM,
        1. Une image de capture que nous créeront,
        2. Un serveur de déploiement sous Windows Server 2012 avec le rôle WDS.

 

Création d’une image de capture

Ajout d’une image basique

Dans le dossier “Boot Images” de la console WDS faire clic-droit puis “Add Boot Image”, une fenêtre apparait et demande le fichier boot.wim disponible dans le fichier sources du DVD d’installation de Windows (E:\sources\boot.wim).

Génération de l’image de capture

Une fois l’image ajoutée il faut en générer une image de capture, et ici, WDS s’occupe encore de tout ! Il suffit de sélectionner l’image tout juste ajoutée avec un clic-droit, puis de sélectionner “Create capture boot Image” comme ceci : 

image_thumb2

Après avoir nommé l’image de capture (nous la nommerons Capture Image) et lui avoir indiqué un emplacement, WDS va générer le fichier .WIM correspondant. 

Ajout de l’image de capture

Tout comme plus haut dans le paragraphe “Ajout d’une image basique” il faut ajouter l’image fraichement générée en indiquant cette fois le chemin donné lors de la génération de celle-ci.

Avec cette image ajoutée, on peut maintenant capturer un OS, c’est à dire en générer un fichier .WIM sérialisé qui nous servira de base lors des futurs déploiements.

Préparation du master

Dans cette partie nous verrons comment préparer le master et comment le sérialiser avec un sysprep.

Installation et intégration des mises à jours

L’avantage d’utiliser une image capturée pour les master et d’y intégrer les éléments communs qu’il serait (bien que possible) long d’ajouter via MDT. Les mises à jour en sont l’exemple parfait, je vous recommande donc de mettre à jour l’OS avant d’en capturer l’image.

On peut aussi penser à d’autres éléments, par exemple il se peut que lors du déploiement du master, le même fichier de données doit être présent sur la machine, dans ce cas il serait également judicieux de l’intégrer avant la capture.

Sysprep

!ATTENTION !

La phase du sysprep est la plus délicate, une fois lancé, l’ordinateur va s’éteindre, et la capture doit immédiatement être prise avant le redémarrage.

Egalement, afin d’économiser en espace lors de la capture du .WIM, penser à bien vérifier qu’il n’y a AUCUN fichier superflu sur la machine.

Aller dans le répertoire suivant :

C:\Windows\System32\sysprep

Puis exécuter l’application sysprep

image_thumb[1]

Cochez la case « Generalize » et sélectionner « Shutdown » dans la droplist « Shutdown Options »

image_thumb[3]

Le sysprep s’exécute puis la machine s’éteint.

Capture

A l’aide de l’outil de l’assistant de capture d’image réalisé dans la partie “Génération de l’image de capture”, la machine sysprepée va maintenant être capturée.

Une fois la machine éteinte il faut :

  • Vérifier que la machine est bien connectée au même réseau que le serveur de déploiement,
  • Démarrer en mode « Network Boot » ou PXE à l’aide de la touche F12,
  • Puis sélectionner l’OS « Capture Image »

image_thumb[5]

L’assistant capture d’image se lance :

image_thumb[7]

Sélectionner le volume à capturer ainsi que le nom de l’image :

image_thumb[9]

Définir l’emplacement (local ou distant) où l’image sera stockée une fois générée :

image_thumb[11]

La capture se lance, une fois celle-ci terminée, l’ordinateur va démarrer, comme celui-ci a été sysprepé, un assistant d’installation va se lancer.

Une fois l’assistant passé, l’image sera disponible à l’emplacement précisé plus tôt.

Utiliser MDT/WDS – Partie 2

Prérequis

  • Avoir réaliser la partie 1 ou, avoir un serveur avec le rôle WDS et un master généralisé,
  • Avoir un serveur avec le rôle MDT.

Intérêt de MDT

L’intérêt de MDT est la gestion pour un OS unique de plusieurs tasks sequences, prenons un exemple, une société a trois type d’utilisateurs tous sur le même OS mais utilisant des applications différentes, des machines différentes (en fonction de la division) et nécessitant chacun une configuration spécifique. Plutôt que de créer trois masters (un pour chaque division), MDT permet en n’utilisant qu’un seul master, de paramétrer plusieurs séquences de tâches spécifiques, évitant à l’administrateur de créer un nouveau master si de nouveaux besoins apparaissent.

Plus encore, synchronisé avec l’AD c’est lors du déploiement que la machine ira automatiquement s’enregistrer sur la bonne OU, avec les administrateurs locaux désignés.

MDT est divisé en plusieurs “Deployment Share” qui peuvent contenir plusieurs OS et plusieurs séquences de tâches.

Liaison entre WDS et MDT

Dans le précèdent poste, nous avons vu que lorsque l’on boot en PXE, WDS ne nous propose que les différentes images de boot. Seulement, une fois notre task sequence prête nous voudrons accéder à celle-ci !

C’est lors de l’import du premier OS que nous allons créer ce qui seras l’interface entre WDS et le Deployment Share de MDT.

Lors de l’ajout d’un OS à un Deployment Share, MDT va générer un ISO nommé ‘LiteTouchPE’, il s’agit d’un « petit Windows » qui va nous permettre de booter et de choisir une task séquence.

Cet ISO est stocké dans :

[DeploymentShare]\Boot\LiteTouchPE_x64/86.iso

Pour accéder au Deployment Share lors d’un démarrage en PXE il va falloir ajouter l’ISO généré dans le dossier ‘Boot Images’ de l’interface WDS.

Import d’une image sysprepé

Après avoir créé un Deployment Share, la première chose à faire est d’importer une image dans le dossier Operating System.

Clique-droit sur ‘Operating Systems’ puis ‘Import Operating System’ :

image

Sélectionner ‘Custom image file’ puis choisir le fichier .WIM créé dans la partie 1, le sysprep ayant déjà été réalisé choisir ‘Setup and Sysprep files are not needed’ :

image

Puis terminer l’assistant d’installation.

Task Sequence

Une fois la task sequence créé, il faut lui indiquer l’OS contenu dans le Deployment Share à utiliser :

image

Et enfin ajouter les applications à installer, par défaut l’étape est déjà présente dans une task sequence tout juste créé, je recommande d’ajouter une étape par application, et de les placer après celle déjà présente (encadré en bleu).

Lorsqu’un changement est fait sur un Deployment Share, il faut actualiser ce dernier :

image

Choisir ‘Optimize the boot image updating process’ puis terminer l’assistant

Applications

Lorsqu’une application est ajoutée, MDT vous demande comment l’installer et ce via la ‘Quiet install command’, par exemple pour Office, c’est la commande  :

setup.exe /config WW\config.xml

image

Vous l’aurez compris, tout dépend de l’application à installer. Pour office (et la plupart des applications Microsoft, on utilise un fichier de config au format XML où toute la configuration y est indiquée.

Pour d’autre applications, comme celles de Symantec, qui n’utilisent pas de fichier de config, il faudra trouver les bonne commande pour l’installation silencieuse, le lien suivant présente les commandes utilisées par les produits Symantec :http://www.symantec.com/business/support/index?page=content&id=TECH83882.

Configuration de MDT

Afin d’augmenter la productivité de MDT, les deux points suivants sont à configurer comme ceci.

Rules

[Default]
DriverSelectionProfile=Nothing
SkipTaskSequence=YES
TaskSequenceID=
OSInstall=YES
SkipAdminPassword=YES
SkipApplications=NO
SkipAppsOnUpgrade=YES
SkipBDDWelcome=YES
SkipBitLocker=YES
SkipCapture=YES
SkipComputerName=NO
SkipComputerBackup=YES
SkipDeploymentType=YES
DeploymentType=NEWCOMPUTER
SkipDomainMembership=YES
SkipFinalSummary=No
SkipLocaleSelection=YES
KeyboardLocale=fr-FR
UserLocale=fr-FR
UILanguage=fr-FR
SkipPackageDisplay=YES
SkipProductKey=YES
SkipSummary=YES
SkipTaskSequence=NO
SkipTimeZone=YES
TimeZone=105
TimeZoneName=Romance Standard Time
SkipUserData=Yes
UserDataLocation=AUTO
JoinDomain=
DomainAdmin=
DomainAdminDomain=
DomainAdminPassword=

Bootstrap.ini

[Settings]
Priority=Default

[Default]
SkipBDDWelcome=YES
KeyboardLocalePE=040c:0000040c
DeployRoot="Chemin du deployment share"
UserID="Utilisateur ayant les droits d'accès au deployment share"
UserDomain="Nom du domaine"
UserPassword="Mot de passe du userID"

Installation de Windows (x64) sur une partition GPT

Depuis l’apparition de l’UEFI (Unified Extensible Firmware Interface) supposé à terme remplacer le BIOS, les disques MBR laissent peu à peu leurs place aux disques GPT qui permettent par disque physique la cohabitation de 128 partitions de 9,4 milliards de To ce qui laisse loin derrière le BIOS et ses 4 partitions de 2,2 To par disque…

Lorsque l’on tente de réinstaller Windows via une clé USB sur une partition de disque en GPT l’erreur suivante apparait :

“Windows cannot be installed on this disk. The selected disk is of the GPT partition style.”

Ce message d’erreur bien peu bavard ne dit rien sur la cause de l’échec, si ce n’est que la partition est de type GPT. L’erreur ici vient en fait de la clé USB, n’étant pas reconnue comme un périphérique compatible UEFI, c’est le BIOS qui prend la relève, et celui-ci voit les partitions GPT uniquement comme étant réservées au données, donc impossible d’y installer d’OS.

Cependant, en modifiant la structure des fichiers d’installation de Windows sur la clé USB, l’installation se déroule comme prévue.

Step 1 – Formater la clé en FAT32

Et oui FAT32 est le format utilisé par l’UEFI, inutile de s’inquiéter pour le moment les fichiers d’installation de Windows 7 et 8 ne dépassent pas les 4Go, de plus le mode de compatibilité permet d’utiliser le NTFS.

Step 2 – Copier les fichiers d’installations à la racine de la clé

 

Step 3 – Récuperer le fichier bootmgfw.efi

Depuis une version x64 de Windows installée sur un système UEFI, récupérer le fichier bootmgfw.efi disponible à cet emplacement : C:\Windows\Boot\EFI\bootmgfw.efi

Step 4 – Modifier l’emplacement du fichier boot

Modifier l’emplacement du fichier boot depuis G:\efi\microsoft vers G:\efi.

 

Step 5 – Renommer et déplacer bootmgfw.efi

Renommer bootmgfw.efi en bootx64.efi et le copier vers G:\efi\boot.

Maintenant que la clé est prête, l’erreur apparue plus tôt n’est plus là, et l’installation de Windows peut continuer normalement.

Déploiement des imprimantes via GPO

L’une des principales utilité des GPOs est d’automatiser des tâches sur un large panel d’utilisateurs (ou d’ordinateur) évitant ainsi à l’administrateur de perdre un temps précieux…

Le déploiement des imprimantes fait partie de ces tâches qui peuvent être un tracas logistique sans l’utilisation des GPOs.

La première étape est la création d’une nouvelle GPO à l’aide de la console “Group Policy Management” dans l’OU où celle-ci s’appliqueras :

image

Une fois la nouvelle GPO créée, ouvrez la console “Print Management”, sélectionnez l’imprimante à déployer via GPO et cliquez sur “Deploy with Group Policy” :

 image

La fenêtre “Deploy with group policy” apparait, cliquez sur “Browse” puis sélectionnez la GPO créée puis cliquez sur OK :

image

Les habitués des GPOs savent sans doute qu’une GPO peut être appliquée au niveau utilisateur, ordinateur ou les deux.

Ce choix dépend de votre organisation interne, j’ai pour ma part choisi le déploiement par utilisateurs :

image

Il faut ensuite cliquer sur “Add” puis sur OK.

A ce niveau l’imprimante est déployée sur les clients à partir de Windows Vista.

Pour la gestion des clients XP, il est nécessaire de passer par une étape supplémentaire car contrairement aux client 7, Vista et 8 qui utilisent “gpprnext.dll” les clients XP et les serveurs antérieurs à Windows Server 2003 utilisent PushPrinterConnections.exe.

Retournons dans la console Group Policy Management.

Sélectionnez la GPO et éditez là :

image

Sous “User Configuration” (ou Computer Configuration en fonction du choix d’application de la GPO fait plus haut), allez dans “Windows Settings” puis “Scripts” :

image

Dans les propriétés du “Logon”, cliquez sur “Add” puis dans “Script Name” choisir PushPrinterConnections.exe (que l’on trouve dans le dossier SYSWOW64 sur Windows Server 2008R2) et dans les paramètres du script tapez “-log” :

 image

Au prochain Logon, vos utilisateurs auront l’imprimantes d’installée sur leur poste, ce sans même que l’administrateur n’ait eu à se déplacer !

Fine-Grained Password Policy – Interface Graphique

Dans les nouveautés de Windows Server 2012 l’interface graphique de gestion granulaire de mot de passe vient simplifier le travail de l’Administrateur en lui évitant de passer par les GPO et ADSIEdit.

La gestion granulaire des mots de passe est déjà disponible depuis Windows Server 2008, un niveau fonctionnel de 2008 suffit donc pour bénéficier de l’interface graphique sur un serveur 2012.

Avant de commencer : il est très probable que dès la mise en place de la stratégie vos utilisateurs aient à changer de mot de passe, or certaines applications ne peuvent le gérer, je vous conseille donc d’appliquer la stratégie une fois vos utilisateurs délogué.

Dans le Server Manager, lancer le tool “Active Directory Administrative Center” :

image_thumb2

Une fois lancé, basculer en vue arborescente (Tree View), puis dans le dossier System, double-cliquer sur le dossier “Password Settings Container”

image_thumb5

Pour créer une nouvelle politique de mot de passe, sélectionner dans l’onglet de droite : New –> Password Setting

image_thumb17

Nous arrivons alors sur cette fenêtre et l’on remarque que Windows Server 2012 se veut intuitif :

image_thumb14

Les textbox précédés d’un astérisque rouge sont des éléments requis pour la création de la stratégie.

Parmi ces éléments, il y a le champ “Precedence”, qui permet – dans le cas déconseillé ou plusieurs stratégies s’appliquerait aux mêmes utilisateurs ou groupes – de gérer quelle stratégie s’applique en priorité.

Une fois le paramétrage terminé, cliquer sur “Add” et la stratégie est immédiatement exécutée pour les utilisateurs concernés.

Supprimer Windows.old sur Windows Server 2012

Depuis Windows Server 2008 l’assistant d’installation est capable de détecter un ancienne installation de Windows Server et – dans le cas où celle-ci est compatible – l’assistant d’installation proposera un “Upgrade” vers l’OS désiré.

L’avantage de l’Upgrade est de conserver la configuration et les rôles du serveur après l’installation du nouveau système d’exploitation. Néanmoins, Microsoft recommande lors de l’installation (ou de la mise à jour) d’un serveur de passer par une “Clean Install”, soit une installation traditionnelle de Windows Server.

Pour information, il est impossible d’Upgrader d’une version 32 bits vers une version 64 bits, la seule solution est de recourir à une Clean Install.


Après une Upgrade du serveur, le dossier utilisé par l’ancien système d’exploitation est toujours présent et a été renommé Windows.old.

Pour supprimer correctement ce dossier il faut passer par le “Disk Cleanup” et les habitués de Windows Server seront surpris par son absence sur Windows Server 2012 :

image

Pour faire apparaitre le bouton Disk Cleanup, il faut lancer en tant qu’administrateur la commande PowerShell suivante :

Add-WindowsFeature Desktop-Experience

image

Voici de retour le bouton Disk Cleanup :

image

Le Disk Cleanup ne propose pas immédiatement de nettoyer le dossier Windows.old, il faut passer par l’option “Clean up system files” :

 image

L’assistant Disk Cleanup commence alors à vérifier les anciennes installations de Windows encore présentes sur le serveur :

image

Après analyse, l’assistant propose de nettoyer les dossiers correspondants aux anciennes installations de Windows :

image

image

En moyenne le gain d’espace fait est d’une dizaine de GB, bien entendu cela dépend de la taille de la précédente installation.