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 :

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” :

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 :

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.

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. 

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.

• 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 :

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 : 

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

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

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 »

L’assistant capture d’image se lance :

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

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

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.

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’ :

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’ :

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 :

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 :

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

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"

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.

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 :

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” :

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

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 :

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à :

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

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” :

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 !

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” :

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

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

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

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.

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 :

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

Voici de retour le bouton Disk Cleanup :

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

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

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

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.

Déjà présente depuis 2008R2 la corbeille AD permet de récupérer des objets accidentellement effacés.

Avec Windows Server 2012, l’utilisation de la corbeille se simplifie avec une interface graphique.

Prérequis à l’activation

Pour activer la corbeille avec GUI, il faut avoir une forêt avec un niveau fonctionnel 2008R2 ou supérieur. Vous pouvez vérifier le niveau fonctionnel de la forêt avec la commande PowerShell suivante :

Get-ADForest | Select forestmode

Activation de la corbeille

Attention, l’activation de la corbeille sur 2008R2 ne permet pas le retour au niveau fonctionnel 2008.

La corbeille AD étant par défaut désactivée il faut l’activer à l’aide de la commande suivante :

Utilisation de la corbeille

La corbeille est activée, il est maintenant possible de tester son fonctionnement avec l’interface GUI :

Supprimez un objet de l’AD

Puis lancez l’Administrative Center et sélectionnez le container “Deleted Objects”

Il suffit de sélectionner l’objet à restaurer puis cliquez sur “Restore” (“Restore To” permet de choisir l’OU dans laquelle l’objet sera restauré)

L’objet est maintenant de nouveau disponible dans l’AD.

Pour aller plus loin dans l’utilisation de la corbeille AD et utiliser des fonctions tel que la restauration de tous les objets en fonction de la date et de l’heure de la suppression, je vous conseille les liens suivants :

- http://blogs.technet.com/b/askds/archive/2009/08/27/the-ad-recycle-bin-understanding-implementing-best-practices-and-troubleshooting.aspx

- http://technet.microsoft.com/en-us/library/dd379481(v=ws.10).aspx