Part 2 – Paramétrage Office 2013

Cet article traite l’intégration de la suite Microsoft Office 2013 dans l’outil Microsoft Deployment Toolkit 2013.

Paramétrage et automatisation Office 2013

Ce chapitre nécessite que vous disposiez d’une version Office 2013 en version Volume License.

Pourquoi utiliser Office Customization Tool ?

Dès maintenant, l’application Office 2013 est prête à être déployée. Cependant, il n’y a aucun mécanisme d’automatisation adapté à un déploiement via MDT. L’installation du produit sera similaire à une installation classique par un DVD (ou tout autre support) avec l’assistant d’installation. L’intérêt de cette option n’est pas adapté à un mode de déploiement de postes de travail industrialisé.

Pour automatiser l’installation de la suite Office, il est nécessaire de générer un fichier de configuration depuis l’outil Office Customization Tool.

Premier paramétrage

Pour commencer, sélectionner dans le Deployment Workbench l’application puis un clic droit. Sélectionner ensuite Properties

Dans la nouvelle fenêtre, vous constaterez qu’il y a quatre Onglets :

          o General

          o Details

          o Dependencies

          o Office Products

Onglet général (commun pour toutes les applications):

Cet onglet permet de définir les informations suivantes :

· Nom, Commentaire, Version, Langage, Répertoire source, le GUID de l’application.

Sur la partie inférieure de la fenêtre, nous trouvons deux options:

· Masquer l’application

· L’application ne sera pas visible sur la partie Applications lors d’un déploiement Lite Touch

· Activer l’application

          o Décocher cette option rend l’application indisponible pour les déploiements

Onglet Détails (commun pour toutes les applications):

Onglet Dependencies (commun pour toutes les applications):

Onglet Office Products (propre et dédié à la personnalisation des applications Office):

C’est dans cet onglet que l’automatisation du logiciel va prendre forme. Pour le moment, une grande partie des champs sont bloqués. Sélectionner le menu déroulant Office Product to Install et Cliquez sur ProPlus.

Remarque : Si vous ne voyez pas le bouton Office Customization Tooll en bas à droite de la fenêtre, c’est que vous utilisez une version Retail. Néanmoins vous pourrez tout de même configurer l’installation sans l’Office Customization Tool. (Traité dans le paragraphe ci-dessous)

Sélectionner l’élément ProPlus dans le menu déroulant. Les champs sont maintenant accessibles et paramétrables. Voici quelques une des options :

· Office language : Si votre répertoire d’installation comporte plusieurs langues, sélectionner celle que vous souhaitez installer.

· Product Key : Ajoute la licence du produit

· Display Level : Paramètre le niveau d’information durant l’installation à l’utilisateur. Trois niveaux sont disponibles :

          o None : Aucune fenêtre ne sera affichée durant l’installation

          o Basics : Le minimum d’information vous sera présenté, l’utilisateur peut suivre la progression de l’installation

          o Full : Niveau par défaut. L’intégralité de l’interface est proposée à l’utilisateur. Aucune automatisation.

· Accept EULA : accepte les termes du contrat d’utilisation

Le bouton Add permet d’ajouter un pack de langue ou une application

Il est possible d’éditer directement ce fichier en cliquant sur Edit Config.xml. La modification des paramètres met à jour le fichier Config.xml dans cette boite de dialogue

Le bouton Office Customization Tool permet de lancer l’assistant. Notez qu’il faut en amont appliquer les modifications avant de pouvoir lancer OCT, sinon le message suivant s’affichera

Je vous propose de traiter dans le troisième article les différentes options permettant de personnaliser l’installation de l’application avec Office Customization Tool.

Le mécanisme de découverte est un des principe fondamentaux de SCOM et constitue un de ses atout majeur : il permet de trouver automatiquement les objets à superviser sur tous les serveurs disposant d’un agent, sans qu’un opérateur n’ait besoin d’indiquer manuellement à chaque nouveau serveur ce qu’il faut superviser dessus.

L’inverse est également vrai : lors de la suppression d’une application ou d’un service sur un serveur, SCOM est capable de s’en rendre compte et cesse de le superviser.

Du moins, la plupart du temps : il arrive parfois que SCOM ne se rende pas compte de ces désinstallations et génère alors un grand nombre d’erreurs infondées.

Quelle en est la raison, et comment y remédier?

Prenons un exemple concret :

Un serveur hébergeait le rôle contrôleur de domaine et ce rôle a été décomissionné.

Cependant, les objets de type SysVol (et d’autres objets propres à un contrôleur de domaine comme Netlogon, NTDS..) sont toujours présents dans SCOM et toujours supervisés, et remontent donc en erreur en générant des alertes.

Si l’on remonte la piste de la découverte de ces objets, on se rend compte qu’il s’agit ici comme souvent d’une découverte en 2 étapes :
– D’abord une découverte légère ciblée sur Windows Computer qui se base sur une requête WMI pour découvrir les instances de la classe Windows Domain Controller :

– Puis une découverte beaucoup plus lourde ciblée sur ces Windows Domain Controllers et qui utilise elle un gros script VBS. C’est cette dernière qui découvre les instances des différentes classes Sysvol, Netlogon & co :

Jusqu’ici, rien d’inhabituel, ce mécanisme est très commun dans les gros management pack.

Imaginons maintenant que nous supprimions le rôle Contrôleur de Domaine d’un serveur. Que se passe t’il dans SCOM?

1. La première découverte ciblée sur Windows Computer s’exécute normalement, se rend compte que la requête WMI n’indique plus la présence d’un DC et supprime donc l’instance de la classe Windows Domain Controller pour notre serveur.

2. Comme il n’existe plus d’instance de la classe Windows Domain Controller pour notre serveur, la seconde découverte ne s’exécute plus sur ce serveur.

Seulement voilà : une découverte qui ne s’exécute pas, ce n’est pas la même chose qu’une découverte qui indique qu’un élément n’existe plus sur le serveur, et les objets Sysvol & co. ne sont donc jamais “dé-découverts”!

Comment maintenant remédier à cette situation?

Il existe un cmdlet Remove-SCOMDisabledClassInstance (Remove-DisabledMonitoringObject dans SCOM 2007) dont l’utilité est de parcourir toutes les règles de découverte présente dans votre environnement SCOM et de supprimer les instances des objets découverts par une règle donnée quand celle-ci est désactivée (via un override) pour l’objet cible de cette découverte.
Autrement dit, il suffirait de créer un Override > for a specific object of class Windows Domain Controller > Enabled = False sur la règle de découverte AD DC local discovery (DC Role), pour l’objet Windows Domain Controller correspondant à notre DC décommissionné.

Sauf que justement, cet objet n’existe plus puisque la première découverte a elle parfaitement fonctionné…
Il faut donc ruser un peu en créant un groupe qui contient l’objet Windows Computer correspondant au DC décommissionné, et d’ensuite créer notre override pour ce groupe :

Une fois l’override crée, on peut enfin exécuter le cmdlet Remove-SCOMDisabledClassInstance. Selon la taille de votre infrastructure, son exécution peut être assez longue comme vous l’indique le message en rouge (à titre d’exemple, il a pris environ 1 à 2 minutes sur un environnement contenant ~200 serveurs et autant de MP).

Et si tous s’est bien passé, les objets découverts par la règle AD DC local discovery (DC Role) sur le contrôleur de domaine décomissionné doivent maintenant avoir disparu.