Jenner VERNAL – BLOG Logorrhee sur les Technologies Microsoft

10avr/130

MAPI sessions exception limit – Explication et correction : Implémenter les stratégies throttlings et la clef de registre

  • Contexte

Ce document à titre informatif permet d'expliquer en détails un problème constaté sous Exchange 2010 avec les quotas appliqués sur les sessions MAPI.

Je vous montrerai ainsi, la cause de ce problème au niveau de Exchange et vous certains symptômes pour pouvoir mieux les identifier.

  • Symptômes

 

Coté poste de travail

  • Client en mode déconnecté (en permanence)
  • Client déconnecté temporairement  (Outlook se retrouverait déconnecté partiellement , un redémarrage de l'application Outlook ou du poste client pourrait corriger le problème temporairement...)

Coté Serveur

  • 1 enregistrement dans l'observateur d'évènement coté serveur similaire à celui-ci :
  • Source : MSExchangeIS ; Event ID: 9646

Mapi session "00cc8dde-64d7-4353-8050-00fc2057aae3: /O=xxxx/OU=xxxx/cn=Recipients/cn=John" exceeded the maximum of 32 objects of type "session"."

•    Causes :

  • Nombre excessif de Sessions/Requêtes MAPI simultanées pour un même utilisateur (Problème de déconnexion/reconnexion intempestives avec une IP différente).
  • Nombre excessif de Sessions/Requêtes MAPI par utilisateurs référents aux fonctionnalités d'Exchange/Outlook (Consultations des calendriers partagés/Visibilité sur la disponibilité des collaborateurs)
  • Nombre excessif de Sessions/Requêtes MAPI par utilisateurs (Nombre de dossiers consultés Par BALs ou présence de BALs partagées par une même personne)
  • Exemple

Commencons par observer les sessions MAPI d'un utilisateur, attention ces manipulation doivent-être réalisées en Exchange Management Shell car le Console d'Administration Exchange ne permet pas de voir ces propriétés :

•    Explication :

Pour l'utilisatrice Marie on voit bien qu'elle consulte en ce moment la BALs partagée du Back Office.

Ce qui génère des sessions MAPI supplémentaires pour le même compte utilisateur.

Cette problématique correspond à des limitations imposées par Exchange pour des raisons de performance :

  • Les Sessions simultanées sont bridées à 16 Sessions sous Exchange 2010 et 32 sous Exchange 2007.
  • Nombres d'objets consultés par sessions MAPI.

•    Historique :

Le problème est connu et maitrisé sous Exchange 2007, une procédure pour clôturer brutalement les sessions MAPI est applicable à l'aide de « TCPView.exe ».

Sous Exchange 2010 l'architecture de l'accès aux Clients a changé.

Nous ne pouvons plus tracer les connexions par IP car le point d'entrée et le point de terminaison des sessions MAPI est 100% crypté et géré entre les serveurs hébergeant les rôles CAS/MBX, à ce jour pour ces raisons nous ne pouvons pas mettre en place une proactivité permettant d'anticiper ce type d'incident. L'outil ExMon permet d'avoir une vue égale à celle de la commande suivante sous exchange 2007 :

Get-Logon Statistics "jsmith" | Sort-Object clientipaddress | Format-Table username,clientipaddress,logontime

Il y a des solutions pour augmenter chaque limitation sous Exchange 2010 :

  • Les Stratégies d'accélération/Optimisation (throttlings policy).
  • Clefs de registres

Avant tout il faut s'assurer que toutes ces modifications (Clef de Registre/Throttling Policy) soient supportées par Microsoft™.

  • Application de l'action corrective :
    • Nombre maximum d'objets consultés simultanément par session MAPI :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeIS

Clefs

MaxObjsPerMapiSession
-> valeur recommandée à 500

  • Afficher les valeurs effectives de la stratégie throttlings par défaut :

    Get-ThrottlingPolicy | ? {$_.IsDefault -eq $true}

  • Nombre de session MAPI simultanées pour les protocoles d'accès aux clients :

    Set-throttlingpolicy "Clients Throttling Policy"

    OWAMaxConcurrency,EASMaxConcurrency,EWSMaxConcurrency,AnonymousMaxConcurrency,RCAMaxConcurrency

  • Application des throttlings policies pour un compte de service BES :

    Créer la stratégie :

    New-ThrottlingPolicy "BES Throttling Policy" -RCAMaxConcurrency:$null

    Appliquer la stratégie:

    Set-Mailbox "besadmin" -ThrottlingPolicy "BES Throttling Policy"

    Vérifier l'application de la stratégie:

    Get-Mailbox "besadmin" | format-list Name,ThrottlingPolicy

  • Superviser les évènements de type Throttlings :

1. Pour activer les logs il faut localiser ce fichier :

C:\Program Files\Microsoft\Exchange Server\V14\Bin Microsoft.Exchange.RpcClientAccess.Service.exe.config

2. Ensuite ajouter throttling à cette ligne comme dans l'exemple suivant :

<add key="LoggingTag" value="ConnectDisconnect, Logon, Failures, ApplicationData, Warnings, Throttling" />

3. Redémarrer le service RPC client Access

25jan/130

SCCM 2012(SCM/DCM/WQL) – Implémenter la Gestion des configurations et de la conformité avec remédiation


Introduction

Cet article a pour but d'expliquer comment émettre des stratégies de gestion de configuration permettant de gérer des postes de travail non-conformes.

Ces stratégies viendront alors mettre à jour les entités identifiées comme « non-conformes » grâce aux moyens de remédiation fournis par la nouvelle version de SCCM 2012.

Pour réaliser cet article ,j'ai pris pour exemple une application : Microsoft Office.
Et un ensemble de machines virtuelles qui formeront mon parc informatique ainsi que mon infrastructure serveur qui gèrera le tout avec SCCM 2012 :)

System Center Configuration Manager contrôlera alors les versions de Microsoft Office installées sur les systèmes de ces machines virtuelles et les mettra à jour automatiquement avec la version requise si elles ne sont pas conformes à la stratégie de configuration grâce à la remédiation automatique.

Avant-Propos

Cet article couvrira les sujets suivants :

  • Comment gérer les configurations d'un poste de travail avec SCCM.
  • Comment évaluer la conformité d'un système avec SCCM.
  • Comment peupler une collection avec une requête WQL personnalisée, basée sur l'état « non-conforme ».
  • Créer une installation automatisée d'office 2010 avec activation automatique.
  • Déployer une application, mise à jour automatique de l'application pour remédier les clients « non-conformes ».

Pré requis

  • Suite Microsoft Office 2007 et 2010/2013 avec OCT
  • Un partage réseau avec les sources d'Office décompressées
  • Rôles SCCM 2012 Distribution et Management Point installés et configurés correctement
  • Un poste client avec un agent SCCM 2012 installé et Office pour réaliser le POC

Gestion de configuration désirée (DCM)

La gestion de configuration désirée a évolué sur SCCM 2012 contrairement à la version 2007.

Il est toujours possible d'importer vos DCM de la version antérieure SCCM 2007.

La« Gestion de la conformité » est déployé sous forme de stratégie,la grande nouveauté est qu'elle permet maintenant de remédier automatiquement les systèmes que l'on peut identifier comme « non-conformes ».

Elle s'implémente en définissant les paramètres de compatibilités suivants :

  • Eléments de configuration
  • Lignes de base de configuration

Créer un élément de configuration

L'élément de configuration permet de définir  un ensemble de paramètre dont-on souhaite évaluer la conformité sur plusieurs types de cibles:

-  Un système d'exploitation (Windows, Mac OS 10, Unix, Linux)

- Des ressources de types périphériques (Serveurs, Stations de travail, Ordinateurs portables, Mobiles)

- un groupe d'utilisateurs

Pour procéder à la création d'un élément de configuration, qui aura pour but de définir la version d'Office installée sur un système. Il va falloir déterminer quel élément pourra nous permettre d'identifier l'application et sa version, ce fichier s'appelle :

« MSO.DLL »

Ce fichier est présent sur tous les systèmes qui ont la suite Office d'installée :

Les propriétés de ce fichier vous donnent la version exacte d'Office :

Une fois que le fichier a été défini nous pouvons créer les éléments de configurations :

Sur la console d'administration SCCM 2012 onglet « Ressources et Conformité » déroulez le dossier « Paramètres de compatibilités » :

Eléments de configuration


Nommez l'élément de configuration comme bon vous semble.

Cocher la case « cet élément de configuration contient des paramètres d'application »Ce qui activera un menu supplémentaire nommé « méthode de détection »cliquer sur suivant.

Le menu « paramètres » permet de définir les conditions pour contrôler les systèmes ciblés.

Cliquer sur ajouter et complétez les champs de cette manière :

Cliquer ensuite sur « parcourir »

Connectez-vous sur un poste qui possède la version Office 2007 et sélectionner le fichier MSO.DLL


La version de fichier à définir doit être égale à celle de votre fichier MSO.DLL :

Votre élément de configuration doit être composé de deux éléments :

  • Une condition existentielle (Non-conforme : Si MSO.DLL existe)
  • Une comparaison de version du fichier (Non conforme : Si La version de fichier MSO.DLL = Valeur 1x.xx.xx.xx)

Comme sur la capture d'écran suivante :

Méthode de détection :

Pour détecter si l'application est installée sur les périphériques SCCM utilise des scripts ou un filtre MSI:

Procéder comme cela pour ajouter le code du produit et sa version :

Créer un autre élément de configuration pour la version d'Office cible.

Pour accélérer la procédure faites un clic-droit sur l'élément de configuration créé précédemment et choisir l'option « copier ». Ce qui dupliquera l'élément de configuration, vous n'aurez plus qu'à modifier la règle existentielle en « Doit Exister » et mettre la valeur du fichier MSO.DLL correspondante à la version cible d'Office :

Une fois que l'assistant de création est terminé avec succès, vous pouvez passer à l'étape suivante.

Créer une ligne de base de configuration

Une ligne de base de configuration peut-être composée de plusieurs éléments de configuration, de définitions de mises à jour logiciels ou d'un ensemble de lignes de base de configurations.

Ce sont-elles qui évalueront la conformité de vos systèmes selon vos configurations désirées.

Pour associer les deux éléments de configurations créés dans l'étape précédente :

Sur la console d'administration SCCM 2012 onglet « Ressources et Conformité » déroulez le dossier « Paramètres de compatibilités » :

Lignes de base de configuration

Nommer votre stratégies et cliquer sur « ajouter », les types d'objets à ajouter sont :

« Eléments de configuration »

Sélectionner ensuite les éléments de configuration qui comparent la version du fichier MSO.DLL.

Dans mon exemple j'utilise deux éléments de configuration pour déterminer si la stratégie de conformité est respectée ou non, les paramètres sont les suivants :

  • Eléments de configuration : Office 2007 = Interdit
  • Eléments de configuration : Office 2010 = Obligatoire

Que signifient ces conditions ?

  • Les périphériques analysés qui vont correspondre à la première règle seront non-conformes.
  • Les périphériques analysés qui vont correspondre avec la deuxième règle seront conformes.

Vous pourrez ainsi dissocier vos périphériques conformes et non-conformes en une seule analyse.

Il est possible d'avoir le même rendu en créant deux Lignes de bases de configuration séparément, une pour la première règle (restrictive) et une seconde pour la deuxième règle (impérative).

Sélectionner votre ligne de base de configuration fraichement créée.

Nous pouvons donc confirmer la création de la ligne de base pour pouvoir ensuite, la déployer sur la collection de périphériques à contrôler :

Sélectionner et ajouter la ligne de base de configuration

Cliquer sur « parcourir » dans le champs « regroupement » :


Une fois le déploiement exécuté, il faut résumer la tâche pour générer les rapports d'analyse.

Procéder de la façon suivante :

Pour surveiller l'avancement de la tâche dirigez-vous sur la console d'administration SCCM 2012 dans le menu « Surveillance », puis le nœud « déploiement », cliquez sur votre ligne de base et faites « afficher l'état » :


Coté poste client le rapport se trouve dans le panneau de configuration :

Il se présente sous forme de rapport XML :

Remédier les périphériques non-conformes

Collection systèmes peuplée dynamiquement

La remédiation automatique peut être appliquée uniquement "quand elle est supportée" par les éléments de configuration de la ligne de base.

Dans le cas contraire « une distribution d'application », il est possible d'utiliser une collection qui aura pour rôle de regrouper tous nos systèmes non-conformes, ainsi nous pourrons déployer
Microsoft Office 2010 qui s'installera automatiquement à l'aide du fichier de réponse généré par l'OCT.

Créer une collection de périphériques

Dirigez-vous dans le menu « Ressources et Conformité » de la console d'administration SCCM 2012, nœuds « regroupement de périphériques » :


Il est possible de peupler dynamiquement une collection en se basant sur des règles.

Pour restreindre l'adhésion à la collection exclusivement aux sujets non-conformes, il faut utiliser une « règle de requête ».

Nous avons besoins de 3 paramètres :

  • Le nom de la ligne de base à sélectionner
  • L'état à filtrer : conforme ou non-conforme
  • L'Identifiant unique de la ligne de configuration

L'identifiant unique est inscrit dans la console d'administration au niveau de l'élément de configuration, il faut ajouter une colonne supplémentaire pour l'afficher.

Pour vous éviter de vous faire souffrir je vous propose une astuce, utiliser une Cmd Let Powershell du module SCCM pour le récupérer dans un fichier texte J :

Ouvrir le module Powershell depuis la console d'administration
SCCM :

Cmd Let:

Get-CMConfigurationItem –LocalizedDisplayName "*office 2007*" | Select LocalizedDisplayName,CI_UniqueID | Out-File C:\CI_UNIQUEID.txt

Modification requête WQL

Modèle:

Select

SMS_R_System inner join SMS_G_System_CI_ComplianceState on SMS_G_System_CI_ComplianceState.ResourceId = SMS_R_System.ResourceId where SMS_G_System_CI_ComplianceState.ComplianceStateName = "<Etat de la conformité>"
and SMS_G_System_CI_ComplianceState.LocalizedDisplayName = "<Nom de la ligne de base>" and SMS_G_System_CI_ComplianceState.CI_UniqueID =
"<ID Unique de l'élément de configuration>"

Requête Personnalisée:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_CI_ComplianceState on SMS_G_System_CI_ComplianceState.ResourceId = SMS_R_System.ResourceId where SMS_G_System_CI_ComplianceState.ComplianceStateName = "Non-Compliant" and SMS_G_System_CI_ComplianceState.LocalizedDisplayName = "Microsoft Office 2007 Verification Version" and SMS_G_System_CI_ComplianceState.CI_UniqueID ="ScopeId_F41FA8FD-237D-4CDF-9A26-30DEFD5D2D1F/Application_ea692da5-5f17-4ff4-9afa-b00d944fc58d/2"

Pour plus de détail sur les class WMI de SCCM vous consulter le lien suivant :

http://msdn.microsoft.com/en-us/library/cc146622.aspx

Modifier l'instruction pour y copier la requête WQL personnalisée :

Afficher la requête par défaut et copier votre requête WQL personnalisée :

    Cliquez sur « Ok » pour finaliser la création de requête

Cliquer sur suivant jusqu'au résumé d'exécution de la création de collection.

Pour afficher les membres de la nouvelle collection et vérifier que vos périphériques « non-conformes » y sont ajoutés :


Préparer le support d'installation d'Office 2010

Microsoft Office possède un outil nommé Office Customisation Tools pour les intimes et les amateurs d'acronymes : OCT.

Pour accéder à l'outil il faut lancer une commande DOS dans le répertoire d'installation d'Office :

Setup.exe /admin

Si vous recevez ce message d'erreur :

Vous avez là une version  « Retail » et donc OCT n'est pas disponible car le répertoire « Admin » n'existe pas dans votre dossier d'installation :

Cet outil est intégré dans la version Volume Licence mais vous pouvez le télécharger ici pour les versions Retail :

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

Comment personnaliser le support d'installation

Une fois l'assistant lancé, 2 choix-vous sont proposés :

  • Créer un nouveau fichier de réponse x86 ou x64 tout dépend de vos sources.
  • Editer un fichier de réponse existant.

L'extension des fichiers de réponse office est en .MSP,
ce fichier est situé dans le répertoire « Updates » du dossier d'installation.

L'assistant de personnalisation est très riche, vous pourrez par exemple définir votre clé d'activation du produit (MAK), rendre disponible ou indisponible des composants de la suite Office, configurer l'affichage du panneau d'installation, retirer l'avertissement de fin d'installation ou encore choisir d'activer automatiquement Office une fois que l'installation est terminée :


Pour indiquer votre clé d'installation de type Multiple Activation Key (MAK) procédez de la façon suivante :

  1. Cliquez sur le menu de gauche : Licences et interface utilisateur
  2. Puis éditez les champs suivants :


Attention !

- Si vous souhaitez avoir une installation complètement automatisée (ZTI) vous devrez cocher la case : « j'accepte les termes du contrat de licence ». Sous peine de devoir l'accepter en cours d'installation.

- Niveau d'affichage : Ce paramètre permet de rendre le setup plus convivial aux utilisateurs.

Je l'ai mis en affichage « Simple » car j'aime bien voir la progression de l'installation s'il y a une erreur… Mais il est possible d'avoir une installation silencieuse en sélectionnant l'option « Aucun ».

Activer automatiquement votre installation d'office

Dirigez-vous sur le panneau de gauche, vers le menu nommé : Modifier les propriétés d'installation :

Le paramètre «AUTO_ACTIVATE» doit-être écrit en capitale.

La valeur à définir est de «1» ce qui signifie que l'on désire activer le paramètre AUTO_ACTIVATE.

A partir de ce point, si vous avez rempli les menus que j'ai cités l'installation d'Office sera automatisée. Vous pouvez donc poursuivre et sauvegarder le fichier de réponse, l'emplacement de stockage est le répertoire « Updates » du dossier d'installation qui contient les sources Office 2010 :


Préparer la bibliothèque d'applications

Après avoir préparé nos sources d'Office 2010 avec OCT,

Il va falloir fournir l'application Office 2010 à notre infrastructure SCCM 2012 (SP1).

Les étapes qui vont suivre peuvent fonctionner autant sur la version de SCCM 2012 RTM que son amélioration SCCM 2012 SP1.

Créer l'application Microsoft Office 2010

Nous allons donc nous diriger sur notre console Configuration Manager 2012 (SP1).

Ouvrez l'onglet « Bibliothèque de logiciels », sélectionnez ensuite le nœud « Applications » :

Cocher le bouton radio : « Spécifier manuellement les informations l'application »


Vous pouvez nommer votre application et laisser le reste des paramètres par défaut, cliquez sur suivant jusqu'au menu « Type de déploiement », puis cliquez sur ajouter.

Une nouvelle fenêtre s'affiche cliquer alors sur le bouton radio :

« Spécifier manuellement les informations du type de déploiement »

Nommer le déploiement comme vous le souhaitez.

Menu « Contenu »

  1. Emplacement du contenu : Définir le chemin UNC du dossier d'installation Office 2010 que vous avez préparé dans la première partie avec OCT dans le dossier correspondant à l'architecture x86 ou x64.
  2. Spécifiez la commande utilisée pour installer le contenu :
    1. programme d'installation : la commande pour installer office est :

    setup.exe

    1. programme de désinstallation : la commande pour désinstaller office est :

    setup.exe /uninstall Proplus


  1. Cliquer sur suivant et ajouter une clause de détection de l'application :

    Cliquer sur « Chemin d'accès »

    Entrer directement le chemin suivant :

    « C:\program files\Microsoft Office»

    Cliquer sur « Nom de fichier ou de dossier » : Office14


Cliquer sur  « Suivant » jusqu'à la fenêtre de confirmation suivante :

Le déploiement de l'application est réservé au prochain chapitre.

Déploiement d'office 2010

Terminons par la tâche de déploiement, qui installera d'Office 2010 automatiquement sur tous périphériques non-conformes de
la collection :

Dirigez-vous dans le menu « Bibliothèque de logiciels » de la console d'administration SCCM 2012, nœuds « Applications » :

Quand l'installation d'Office sera terminée l'agent rapportera au serveur SCCM que l'application a été installée avec succès. Les périphériques seront donc conformes au prochain passage de la ligne de base de configuration, par la suite ils seront supprimés automatiquement de la collection :



Conclusion

Aujourd’hui nous avons vu l’implémentation des stratégies de gestion de configuration et de conformité pour mettre à jour la configuration d'un poste de travail en s’appuyant sur les fonctionnalités offertes par System Center Configuration Manager 2012. Vous pourrez maintenant planifier le déploiement de vos nouvelles applications avec un meilleur contrôle des configurations sur vos devices.

27nov/120

Script Login vSphere avec PowerCLI

vSphere PowerCLI est un freeware très intéressant édité par VMware.Celui-ci à la particularité de s'appuyer sur le Windows Powershell. Ce dernier étend les capacités d'administrations et d'automatisations.

Il représente pour les administrateurs VMware une alternative à la connexion SSH sur les ESX pour les tâches d'administration.

Dans mes quotidien, je suis amener à travailler sur plusieurs serveurs vSphere dans différents DataCenter du globe avec un bon milliers de VMs (Serveurs,VDI,Workstations...). J'ai donc décidé de créer un script en Powershell pour faciliter la connexion aux multiples serveurs vSphere.

Ce script très simple permettra de vous connecter à vos serveurs vSphere sans devoir entrer manuellement chaque nom d'hôte et par la même occasion votre identifiant .

# Demander les identifiants de connexion à vSphere Client (les même que sur le GUI)

$cred = get-credential

# Créer une liste d'objets Noms de serveurs vSphere faisant office de portail entre le client vSphere et le serveur ESX

$server = "Paris-vsp001","Newyork-vsp001","Hongkong-vsp001","SaoPaulo-vsp001"

# Executer la commande Connect-VIServer pour chaque entrées dans la variable $server

foreach ($servers in $server) {Connect-VIServer -Server $servers -Credential $cred}

Un dernier tip fort sympathique : Quand vous revenez de vacances et que vous avez oublié les noms de vos serveurs vSphere :)

Connect-Viserver -Menu ; ce qui donne :

27nov/120

Automatiser l’installation de Active Directory

Le sujet d'aujourd'hui concerne la nouvelle méthode de déploiement d'un DC et de ses binaires plus particulièrement par Script.

 

Si vous ne connaissez pas les nouveautés apportées à Active Directory grâce aux fonctionnalités de management et d'intégration avec les modèles de Cloud Computing proposés par Windows Server 2012 ™, je vous invite à consulter ce lien :

 http://bit.ly/ToV4mn

 

  • Un peu d'historique :

 

Auparavant il y avait deux méthodes pour Promouvoir un serveur en tant que Contrôleur de domaine :

- Script en langage : VBscript (environ 20 lignes de code)

- Assistant de promotion d'un contrôleur de domaine avec fichier de réponse :

DCPROMO.exe /answer (NT 5.2) ou /unattend (NT.6.0 et  NT 6.1)

 

Mais pourquoi nous compliquer la vie alors que Microsoft à mis au point un langage de script maintenant ancien de 6 ans qui est beaucoup plus simple que VBScript.

 

"Heu ?  KESAKO ?!"

 

Si vous ne le connaissez pas encore je vous présente : Le fameux "POWERSHELL"

 

L'une des étapes des plus excitante mais qui peut s'avérer très vite fastidieuse lors d'un projet de mise en œuvre d'infrastructure à grande échelle est sans doute la méthode employée pour déployer nos produits.

 

Vous serez certainement amené à vous poser ces questions :

 

"La méthode que j'utilise est-elle la plus efficace ?"

"Est-ce que cette procédure de déploiement est adaptable/améliorable bien même portable ?"

 

Imaginez vous dans le contexte d'un sinistre majeur ou d'un déploiement d'une centaine de Contrôlleurs de domaine.Quelque soit l'objectif, sans hésiter vous choisirez d'utiliser la méthode du Scripting.

 

Alors pourquoi ne pas créer un script qui guidera notre utilisateur pendant les étapes d'installation et de paramétrage comme le fait ci-bien un assistant graphique ?

 

Quels sont les bénéfices :

 

- Apporter plus de contrôle pendant les étapes de mise en Œuvre de votre environnement technique :

 

  • Eviter le facteur humain : Mauvais paramètres renseignés, non respect de votre nomenclature ou simple erreur…

 

  • Le manque de connaissance de votre environnement peut entrainer la divulgation de mot de passe propre à votre SI (Par exemple le mot de passe d'un compte ayant tout les privilèges de votre domaine AD que l'on retrouve souvent sous le clavier d'un opérateur ou écrit sur un bout de papier chiffonné dans une corbeille).

 

- Accélérer la procédure de mise en œuvre pour vous concentrer sur d'autre aspects technique/administratif du déploiement.

 

- Nul besoin de définir des comptes avec délégations de privilèges dans le cas où les tâches de mise en œuvre seraient confiées à des prestataires externes, que le déploiement soit intégral ou bien même partiel.

 

Si l'administrateur sait quels sont les paramètres essentiels pour mener à terme le déploiement, il pourrait choisir d'intégrer à son script des boîtes de dialogue pour permettre de personnaliser la tâche et de rendre le script plus convivial.

 

  • Pour la partie technique pure c'est ici :

 

##############################################################################

#

# Unattend_DCPROMO.ps1

#

# V.01 The 26 November 2012 by Kévin KISOKA –

# Personal Website : http://www.it-deployment.fr

#

#

#         

#          Usage :

#          - Modules Work Only with Powershell 3.0 / .NET 4.0 is required.

#          - Install silently ADDS Binaries.

#          - Store DSRM Password in secure string in a text file for reusing like MSFT recommends.

#          - Prompt Only for required PROMOTE parameters like sysvol/ntds/logs folder path.

#

#

##############################################################################

 

 

 

# Import ServerManager Module to install ADDS Binaries

 

Import-Module "Servermanager"

 

# Check If ADDS Binaries are already installed on the computer

 

$check = Get-WindowsFeature | ? {$_.Name -Like "AD-Domain-Services" -and $_.InstallState -eq "Installed"}

 

If ($check -eq "true") {write-host "******* Installation of Binaries is Ok, DC PROMOTE JOB Can now start *******" -ForegroundColor Yellow}

 

# Install Windows ADDS Binaries

 

ElseIf ($check -ne "true") {Add-WindowsFeature AD-Domain-Services -IncludeManagementTools}

 

# Confirm Binaries Installation is good

 

If ($_ -eq "Success") {write-host "******* Installation of Binaries is Ok, DC PROMOTE JOB Can now start *******" -ForegroundColor Yellow}

 

 

Elseif ($_ -ne "Success") {Add-WindowsFeature AD-Domain-Services -IncludeManagementTools}

 

 

# Input all parameters required to install Forest And Domain ADDS

 

 

$netbiosname = Read-Host 'What NETBIOSDOMAIN NAME you desire ? Limit length is 15 Characters'

$Domain = Read-Host 'What Full Qualified Domain Name you desire ?'

$NTDSPath = Read-host 'What NTDS.DIT Database Folder Path do you Desire ?'

$NTDSLogpath = Read-host 'What NTDS.DIT LogFolder Path do you Desire ?'

$SysvolPath = Read-host 'What SYSVOL Folder Path do you Desire ?'

 

# Store password Admin in a secure string

 

$file = "c:\pw.txt"

$pw = Read-host -prompt "Password:" -assecurestring

$pw | ConvertFrom-SecureString | Set-Content $file

 

 

# Launch Promote Job

 

Install-ADDSForest -DomainName $Domain -DomainNetBIOSName $netbiosname -safemodeadministratorpassword (Get-Content $File | ConvertTo-SecureString) -SkipAutoConfigureDNS -SkipPreChecks -InstallDNS:$true -SYSVOLPath $SysvolPath -DatabasePath $NTDSPath -LogPath $NTDSLogpath -WhatIf

 

# Confirm Installation Completion and Debug Logs location

 

Write-Host "****** Installation In Progress ! You will find debug data of the installation process in %systemroot%\debug\dcpromo.log ******" -ForegroundColor Green -NoNewline

 

  • Lexique:

 

Utilisations des paramètres de la commande Install-AddsForest :

 

-WhatIf: Permet d'indiquer au moteur PSH d'utiliser les valeurs par défaut de l'assistant si vous n'avez pas répondu explicitement aux boites de dialogues comme démontré ci-dessous :

 

-SkipPreChecks : Permet de passer les étapes de vérification des pré-requis binaires (.NET 4.0/OS WS 2012, Paramètres de délégation DNS …)

 

-SkipAutoConfigureDNS : Permet d'éviter la passe de vérification des pré requis du type suivant :

 

Paramètres client DNS , Forwarders, Root Hints, Carte Réseau en mode DHCP.

 

* Ces paramètres sont généralement configurés après installation complète du premier DC avec le rôle Serveur DNS.

 

  • Le script peut être amélioré ou personnalisé pour les types d'installations suivants :

 

- Niveau fonctionnel du Domaine/Forêt (Paramètre -DomainMode et -ForestMode)

 

- Nouveau domaine dans une forêt existanteATTENTION! Il n'est plus question d'utiliser la Command Let "Install-addsforest" mais plutôt celle-ci :

 

Install-AddsDomain -DomainType "TreeDomain","ChildDomain"

 

Pour conclure cet article vous aurez plus d'informations détaillées à cet emplacement :

 

http://technet.microsoft.com/fr-fr/library/jj574166.aspx

 

Et si vous souhaitez avoir les scripts en VBS pour les versions d'OS antérieurs(WS 2003 ou 2008 R2) vous pouvez contacter Jenner VERNAL ou moi-même Kévin KISOKA via le réseau social Linkedin ou ce blog.

25nov/120

Préparer un modèle de VM Windows 8

En un an Microsoft aura renouvelé l'ensemble de ses produits ou presque.

Afin de s'y retrouver dans ce dédale de nouveautés quoi de mieux que de mettre les mains dans le cambouis en triturant ces nouvelles versions.

Après avoir vu comment préparer un modèle de machine virtuelle pour Windows Server 2012. On fera ici de même avec le client : Windows 8 couplé a Office 2013 tout deux RTM depuis peu.

Plan

  1. Création des fichiers de réponses
  2. Installation de Windows 8 – Mode Audit
  3. Personnalisation de l'image d'installation
  4. Généraliser l'installation

Création des fichiers de réponses

Comme dans l'article précédent, nous utiliserons Windows ADK. Celui-ci est disponible en version final et nous permet entre autres de préparer les fichiers de réponses via l'utilitaire Windows System Image Manager. Je vous renvoie à mon article précédent concernant l'installation.

Nous allons procéder à la création de 2 fichiers de réponses :

  • L'un sera utilisé lors de l'installation initiale de l'OS
  • Le second lui pour effectuer des actions particulières lors du Sysprep.

Avant de commencer il faut copier le fichier Install.wim dans un emplacement où l'on dispose de permissions d'écriture.

En effet à ce jour, les fichiers catalogues sont absents des supports d'installation distribués par Microsoft. Puisqu'ils sont nécessaires, nous les générons nous-même.

Dans Windows SIM, sélectionnons l'image Windows issue du fichier install.wim que nous venons de copier.

Celui s'acquittera de la création du fichier catalogue

Nous voilà prêt à créer un nouveau fichier de réponses

Dans la section Image Windows, nous ajouterons les composants aux étapes de configuration du fichier de réponses

Composant Etape de la configuration
Microsoft-Windows-Deployment\Reseal oobeSystem
Microsoft-Windows-IE-InternetExplorer Specialize
Microsoft-Windows-IE-InternetExplorer\SearchScopes Specialize
Microsoft-Windows-International-Core oobeSystem
Microsoft-Windows-International-Core-WinPE WindowsPe
Microsoft-Windows-International-Core-WinPE\SetupUILanguage WindowsPe
Microsoft-Windows-Setup\UserData WindowsPe
Microsoft-Windows-Shell-Setup Specialize
Microsoft-Windows-Shell-Setup\Autologon AuditSystem
Microsoft-Windows-Shell-Setup\UserAccounts\AdministratorPassword oobeSystem

Une fois les composants ajoutés dans les sections correspondantes. Nous y définirons les valeurs nécessaires.

Composant Valeur
Microsoft-Windows-International-Core-WinPE InputLocale= fr-FR
SystemLocale= fr-FR
UILanguage= en-US
UIlanguaageFallBack= en-US
UserLocale= fr-FR
Microsoft-Windows-International-Core-WinPE\SetupUILanguage UILanguage= en-US
Microsoft-Windows-Setup\UserData AcceptEula=True
FullName= JVN
Organization
Microsoft-Windows-IE-InternetExplorer DisableAccelerators= true
DisableFirstRunWizard= true
DisableOOBAccelerators= true
Home_Page= about:blank
Microsoft-Windows-IE-InternetExplorer\SearchScopes
(faites un clic droit sur le composant puis "Insérer un nouvel élement Scope")
ScopeDefault= true
ScopeDisplayName= Google
ScopeKey= Google
ScopeUrl=

http://www.google.com/search?q={searchTerms}

Microsoft-Windows-Shell-Setup (4 specialize) RegisteredOwner= Jenner VERNAL
TimeZone = Romance Standard Time
Microsoft-Windows-Shell-Setup\Autologon (5 auditSystem) Enabled= true
LogonCount= 5
Username= Administrator
Microsoft-Windows-Shell-Setup\Autologon\Password (5 auditSystem) Value = password
Microsoft-Windows-Deployment\Reseal Mode= Audit
Microsoft-Windows-International-Core InputLocale= fr-FR
SystemLocale= fr-FR
UILanguage= en-US
UIlanguaageFallBack= en-US
UserLocale= fr-FR
Microsoft-Windows-Shell-Setup\UserAccounts\AdministratorPassword
(7 oobeSystem)
Value = password

Nous enregistrons ce premier fichier sous le nom AutoUnattend.xml

Maintenant, tachons de créer le second fichier de réponses. Tout d'abord les composants.

Composants Etape de la configuration
Microsoft-Windows-International-Core oobeSystem
Microsoft-Windows-Security-SPP generalize
Microsoft-Windows-Shell-Setup specialize
Microsoft-Windows-Shell-Setup\Autologon oobeSystem
Microsoft-Windows-Shell-Setup\OOBE oobeSystem
Microsoft-Windows-Shell-Setup\UserAccounts oobeSystem

Et ensuite les valeurs

Composants Valeur
Microsoft-Windows-Security-SPP SkipRearm= 1
Microsoft-Windows-Shell-Setup (4 specialize) ComputerName= *
Microsoft-Windows-International-Core InputLocale= fr-FR
SystemLocale= fr-FR
UILanguage= fr-FR
UILanguageFallback= fr-FR
UserLocale= fr-FR
Microsoft-Windows-Shell-Setup\Autologon (7 oobeSystem) Username= Administrator
Enabled= true
LogonCount= 15
Microsoft-Windows-Shell-Setup\Autologon\Password (7 oobeSystem) Value = password
Microsoft-Windows-Shell-Setup\OOBE (7 oobeSystem) HideEULAPage= true
HideLocalAccountScreen= true
HideOEMRegistrationScree= true
HideOnlineAccountScreens= true
HideWirelessSetupInOOBE= true
NetworkLocation= Work
ProtectYourPC= 3
Microsoft-Windows-Shell-Setup\UserAccounts\AdministratorPassword (7 oobeSystem) Value = password
Microsoft-Windows-Shell-Setup\UserAccounts\LocalAccounts (7 oobeSystem)
Faites un clic droit puis "Insérer un nouvel élement LocalAccount"
DisplayName= Administrator
Group= Administrators
Name= Administrator
Description= Compte d'utilisateur d'administration
Microsoft-Windows-Shell-Setup\UserAccounts\LocalAccounts\Password (7 oobeSystem) Value = password

Celui-ci enregistré sous le nom Sysprep.xml

Installation de Windows 8 – Mode Audit

En disposant nos fichiers de réponses et surtout l'AutoUnattend.xml dans le support d'installation le programme d'installation prendra automatiquement en paramètre les indications du fichier.

Le 1er a pour but de réaliser une installation semi-automatisé de Windows 8. Seuls quelques critères restent à définir manuellement :

L'édition à installer.

Ainsi que le Partitionnement du disque (par défaut pour BitLocker : une de 350Mo Réservé au système et le reste pour l'OS ou alors créer une seule et unique partition)

Des paramètres moins importants sont définis : nom de propriétaire et organisation ainsi que paramètres régionaux et linguistiques.

Mais surtout, le fichier tâche de configurer le mot de passe du compte Administrator par défaut et saute l'étape Out Of Box Experience (ou l'on doit notamment créer les comptes locaux, configuration Wifi, Windows Update) pour nous ramener sur le mode Audit.

Sur Windows 8 le mode Audit réactive le compte Administrator Intégré (peu importe la langue de votre ISO)

Après moult redémarrage, nous obtenons ceci :

On peut d'ailleurs constater que le Modern UI Start Menu est épuré par rapport à une session classique. L'utilitaire Sysprep, lui, nous attend une fois qu'on clique sur Desktop

Personnaliser de l'image d'installation

Cette 2eme étape dépend essentiellement de vos besoins. Vous pouvez y intégrer des réglages et personnalisations qui seront disponible sur toutes les machines déployées à partir de ce master. Bien entendu si vous partez d'une ISO déjà en français vous sauter quelques étapes.

Mes modifications seront très légères. Dans l'ordre :

  1. Activation de l'OS

  1. Installation du package de langage français via LPKSetup si vous avez l'ISO multilingue Windows 8 ou d'ici peu sur Windows Update. Pour rappel les MUI Pack sont dispos sur toutes les éditions de Windows 8.

  2. Définir la langue par défaut via la commande

    control /name Microsoft.Language

    Mais également changer la langue de l'écran d'accueil et des nouveaux comptes utilisateurs

    Intl.cpl > Administration > Copier les Paramètres

  3. Installation d'Office 2013 et Activation
  4. Configuration de BackInfo avec raccourci dans %ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup.
  5. Installation de Classic Shell ou Start8. Totalement optionnel, mais plus pratique pour naviguer dans une menu démarré sous une VM
  6. Désactiver l'animation lors de la première ouverture de session

    Gpedit.msc > Configuration d'Ordinateur > Modèles d'Administration > Système > Ouverture de Session. Puis « Afficher l'animation à la première connexion ».

Une fois terminé on peut passer à la dépersonnalisation de l'installation

Généraliser l'installation

Cette étape se résume en l'exécution d'une commande : Un sysprep qui utilisera le second fichier de réponses sysprep.xml.

Qu'il y a-t-il dans ce fichier de réponses ?

  • Paramètres de langue totalement en Français.
  • Ne pas réinitialiser la période de grâce (en somme conserver la machine activée)
  • Esquiver tous les écrans OOBE : Wifi, création de compte local, CLUF etc.
  • Générer automatiquement le nom de l'ordinateur
  • Mot de passe du compte admin sur « password »
  • Activer le compte d'Administration par défaut.

Attention : Quelque soit la langue de votre source d'installation, le compte d'administration est bien et bien AdministratOr.

Dans la console MMC et l'éditeur de registre il est fait mention du compte d'administration dans la langue de Shakespeare.

Ce comportement est dû au démarrage en mode Audit.


Cependant lors du Sysprep, nous basculerons l'ensemble des paramètres de langue. Il en sera de même pour le compte d'Admin, il sera renommé Administrateur. Par conséquent ce fichier Sysprep.xml crée précédemment ne pourra être exécuté une seconde fois sur cette machine que si les paramètres d'activation du compte d'Admin sont modifiés et localisés dans la bonne langue.

Pour préparer cette machine pour la duplication, nous exécuterons la commande suivante :

C:\Windows\System32\Sysprep\Sysprep.exe /generalize /oobe /shutdown /unattend : «Chemin vers le fichier sysprep.xml » /mode:vm

Vous pouvez poser le fichier sysprep.xml sur un support amovible ou sur un partage réseau. Le laisser en local sur la machine c'est le rendre disponible après déploiement de vos machines. Dans ce fichier se trouve le mot de passe administrateur local même si il n'est pas stocké en clair et peut être la clé produit.

Sysprep sous Windows 8 peut être désormais effectué jusqu'à 999 fois avec ou sans rearm. De plus il embarque un nouveau commutateur : le /mode:vm

Quels sont ses avantages et inconvénient ?

  • Il n'est disponible uniquement pour les installations en machine virtuelle
  • Vous ne pouvez l'utiliser sur un disque dur virtuel destiné à être redéployé sur le même type hyperviseur (Hyper-V pour Hyper-V, VMWare pour VMWare).
  • Ne s'exécute uniquement en ligne de commande
  • Ne peut pas être utilisé pour un déploiement sur un autre ordinateur
  • Accélère le démarrage initial (48% selon mes tests)

Après extinction de la machine il n'y a plus qu'à dupliquer le fichier VHD, ou créer un modèle de VM sous ESX.

Dans le cadre d'un déploiement sur machine physique, vous pouvez enchainer sur la création d'un fichier WIM. Vous avez un panel assez important de méthode pour cette étape tel WADK lui-même (en créant un WinPe Bootable avec GImageX), MDT, WDS pour ce citer qu'eux.