Lorsque l’on développe ses propres Management Packs, il arrive fréquemment que l’importe échoue pour des raisons diverses (bout de code oublié, mal placé, mauvaise référence…).

Dans ces cas, l’assistant d’importation des MP retourne normalement une erreur plus ou moins explicite qui permet, après un peu de déchiffrage et avec l’habitude, de localiser assez efficacement la cause du problème.

J’ai par contre été confronté aujourd’hui à un cas inhabituel : après l’ajout manuel (en modifiant le code XML directement à l’aide d’un éditeur de texte) d’une règle à un MP pré-existant, l’assistant a refusé l’import avec une erreur “vide” (ou pour ainsi dire sans erreur ) :

Après quelques heures de questionnements existentiels, de relecture de mon code, de tests en recréant la règle dans un autre MP (là, ca fonctionnait!), j’ai fini par mettre le doigt sur le problème :

La règle que j’avais ajouté contenait un Consolidator (d’où la création manuelle et pas via la console de SCOM), qui était appelé via la ligne

<ConditionDetection ID=”CD” TypeID=”System!System.ConsolidatorCondition”>

Alors que dans mes déclarations de références, le MP System.Library était déclaré avec l’alias SystemLibrary7585010 et non pas System.

Visiblement, l’assistant d’import de MP n’a pas su me signaler cette simple erreur de référence dans ce contexte précis, alors qu’il en est normalement parfaitement capable…

Une erreur bête qui m’aura tout de même fait perdre plusieurs heures!

Vous souhaitez déployer une seconde instance de votre service avec un nom prédéfinit mais lorsque vous vous apprêtez à déployer votre VM, un message d’erreur apparait :

Cependant, dans votre Cloud privé, aucune machine virtuelle de ce nom n’est présente.

Pour remédier à ce problème, il est nécessaire d’accéder à la base de donnée VMM sur le serveur SQL et de supprimer l’entrée présente avec ce nom de VM.

Connecter vous sur votre base de donnée VMM

Aller sur la table tbl_WLC_VMDeploymentConfig

Editer la table et rechercher la colonne ComputerName et identifier votre nom de VM posant problème.

Supprimer la ligne du tableau.

Le problème de la VM déjà existante lors du Scale-Out dans VMM n’apparait plus. La VM peut être déployée.

Cet article expose une astuce qui est susceptible de vous faire gagner du temps dans les phases de packaging de vos applications.

Contexte

Après quelques expériences en packaging sur ConfigMgr 12, on s’aperçoit très vite que le temps nécessaire traiter une application est extrêmement variable d’une application à l’autre. Néanmoins, je ne pense pas me tromper en disant que la tâche est simplifiée dans le cas où le fichier d’installation se présente sous la forme d’un « Windows Installer MSI ». En effet, Configuration Manager prend en charge plus facilement et détecte de nombreuses informations sur votre application. Voici par exemple quelques éléments qui sont automatiquement ajoutés :

· Informations générales (nom de l’application, version, build, éditeur…)

· La ligne de commande d’installation

· La ligne de commande de désinstallation

· Les paramètres de détection

Notez que certaines informations sont valables pour l’application, mais aussi pour le Type de déploiement Windows Installer qui est lui aussi automatiquement généré. On évite ainsi la double saisie des informations.

Remarque : Rien ne vous empêche par la suite de modifier les champs préremplis, je pense notamment aux champs d’installation et désinstallation pour greffer un éventuel script personnalisé.

Un fichier MSI étant généralement plus rapide à mettre en œuvre qu’un fichier EXE, voyons à présent une astuce pour tenter d’obtenir un fichier MSI à partir d’un EXE.

Comment obtenir un fichier MSI à partir d’un fichier EXE ?

Les éditeurs mettent généralement à disposition des fichiers d’installation parfois en fichier EXE, MSI ou EXE + MSI. Dans le cas où le MSI n’est pas disponible, voici une astuce pour tenter d’obtenir le fichier. La méthode présentée ne fonctionne pas à tous les coups, mais elle est si rapide à mettre en œuvre qu’il serait dommage de ne pas essayer.

Situation type : vous devrez ajouter une application dont la source d’installation est un fichier portant l’extension .EXE.

1. Lancer le fichier d’installation et au besoin avec une élévation avec un compte disposant des droits suffisants

2. L’installer se charge et affiche une première fenêtre de bienvenue.

3. À cet instant, rendez-vous dans le répertoire C:\Users\Votre_User\AppData\Local\Temp

Attention, il s’agit ici du compte avec lequel vous avez réalisé l’élévation de droit.

4. Le répertoire est susceptible d’être assez conséquent. Trier donc les éléments par date et rechercher un répertoire ou des fichiers MSI qui correspondent à l’heure de l’exécution du fichier.

5. Vous avez identifié un répertoire / fichier ? Vérifier qu’il s’agit bien de l’application recherchée. Notez qu’il est très fréquent que les éditeurs de logiciel encapsulent dans les fichiers EXE un premier exécutable en 32 Bits et un second en 64 Bits.

6. Si vous ne trouvez aucun fichier, c’est que le programme d’installation n’a pas réalisé d’extraction dans ce répertoire. Vous pouvez essayer de regarder également dans le répertoire : C:\Windows\Temp

Remarque : dans le cas où l’installation devra être réalisée avec des options d’installation spécifique, il faudra vérifier que le fichier MSI extrait peut réaliser une installation conforme et similaire au fichier EXE.

Contexte

Votre infrastructure System Center Configuration Manager est en production depuis plusieurs mois. La liste des applications disponibles devient de plus en plus grande et votre espace de stockage libre devient faible et atteindra bientôt un seuil critique. Vous envisagez probablement d’orchestrer une vaste opération de déplacement du répertoire contenant les sources d’installations de vos applications. C’est ce sujet que je vous propose d’aborder dans cet article à travers un retour d’expérience.

Détail des opérations

Une première étape préliminaire consiste à copier le répertoire « Sources » vers votre nouvel espace de stockage. Que ce soit un partage simple ou un espace de nom DFS je ne détaillerai pas davantage cette étape. Les données étant maintenant physiquement prêtes sur le nouvel espace cible, nous pouvons passer à la seconde étape.

L’opération suivante consiste à modifier dans ConfigMgr l’emplacement pour accéder aux fichiers d’installation. Elle pourra être menée par deux méthodes:

· La première consiste à utiliser l’interface graphique. Aucune opération en amont n'est à prévoir. Cependant, cette tâche répétitive s'accentue fortement au fur et à mesure que le nombre d’applications tend à croître.

· La seconde s’appuie sur l’exécution d’un script qui réalisera la migration en masse et de façon automatisée.

Voyons à présent les détails des actions à mener pour réaliser cette tâche

En graphique

Rien de plus simple: sélectionner votre application dans votre « Bibliothèque de logiciel », accéder aux propriétés du « type de déploiement » et repérer le champ « Emplacement du contenu ». Saisir l’UNC ou cliquer sur « Parcourir » pour renseigner le nouveau chemin. Validez ensuite le changement en cliquant sur « OK » ou « Appliquer » et le tour est joué.

En PowerShell

Un script PowerShell pourra être mis en place pour traiter l’opération de façon automatisée. Le choix d’implémenter cette méthode repose principalement sur le nombre d’applications à traiter. Un temps de préparation supplémentaire pour mettre en œuvre le script est à prévoir. C’est pourquoi vous devriez probablement privilégier cette méthode si le nombre d’applications est un multiple de cinquante ou plus.

Je ne peux rentrer dans les détails sur les opérations à mener dans le cadre de ce blog mais plusieurs articles sur le Web traitent le sujet et détaillent le script à mettre en œuvre. Vous pouvez donc vous en inspirer et l’adapter en fonction de votre besoin. Voir la section Ressources externes en bas de la page.

Impacts

Cette section porte sur une analyse des impacts potentiels sur vos servers et postes client.

Impact infrastructure ConfigMgr

Les applications modifiées seront dotées d’un nouveau numéro de révision. Une nouvelle copie du répertoire contenant la source sera donc envoyée sur les points de distribution. Un temps de propagation sera donc nécessaire pour distribuer le nouveau contenu. En cas de problème, vous pourrez envisager une opération de « Roll Back » par l'application de la révision précédente.

Impact des postes clients

Du côté des postes client et de leurs « Centre logiciel », cela se traduira par une actualisation des applications :

- Si l’application est déjà installée sur le poste, elle apparaitra de nouveau dans l’onglet « État de l’installation » comme étant « Installée ».

- Si l’application est obligatoire et qu’elle n’était pas installée sur le poste, l’agent lancer la phase d’installation.

- Si l’application est dans un état « Échec », l’agent va tenter d’installer l’application une nouvelle fois. N’ayant pas modifié le processus d’installation, il n’y a pas d’illusion à se faire sur l’issu de l’installation.

Pour conclure, il y a donc peu de risque à réaliser cette opération sur votre environnement

Ressources externes

Voici quelques liens qui traitent le sujet de la migration par script Powershell.

http://blogs.technet.com/b/configmgrdogs/archive/2013/05/09/package-amp-application-source-modification-scripts.aspx

http://www.verboon.info/2013/05/how-to-change-the-sccm-2012-package-source-path-with-powershell/

https://andrewdcraig.wordpress.com/2013/01/31/configmgr-2012-change-application-source-path/

Le script ci-dessous surveille la consommation (création / suppression) régulière de fichiers dans un dossiers en excluant potentiellement des noms de fichiers et des heures de dernieres modification puis remonte l’état a SCOM.

Lien du script plus bas.

Suite à la distribution de la mise à jour de sécurité Office MS14-082 le 9 décembre 2014, vous rencontrez un problème avec l’exécution de vos documents Excel contenant des macros et contrôles ActiveX ? Si la réponse est oui, cet article peut vous intéresser.

Comment se matérialise l’incident ?

Selon l’article officiel disponible ici, Microsoft liste plusieurs symptômes permettant d’identifier l’incident. Pour faire simple suite à l'application de la mise à jour, l’incident vous empêche d’exploiter vos fichiers Office contenant des macros et contrôles ActiveX. Dans notre situation, l’activation du contenu actif d’un fichier Excel contenant des macros était devenue tout simplement impossible.

Dans le détail : L’installation de la mise à jour créée une désynchronisation des bibliothèques de types de contrôle mises en cache (Fichiers portant l’extension .exd)

Vous trouverez ci-dessous les références des mises à jour qui génèrent l’incident :

· Security Update for Microsoft Office 2007 suites (KB2596927)

· Security Update for Microsoft Office 2010 (KB2553154)

· Security Update for Microsoft Office 2013 (KB2726958)

Quels sont les produits impactés ?

Les suites Office 2007, 2010 et 2013 peuvent être impactées par l’installation du correctif. En détail :

· Microsoft Excel 2013

· Microsoft Word 2013

· Microsoft PowerPoint 2013

· Microsoft Visio Standard 2013

· Microsoft Visio Professional 2013

· Microsoft Excel 2010

· Microsoft Word 2010

· Microsoft PowerPoint 2010

· Microsoft Visio Professional 2010

· Microsoft Visio Premium 2010

· Microsoft Visio Standard 2010

· Microsoft Office Excel 2007

· Microsoft Office Word 2007

· Microsoft Office PowerPoint 2007

· Microsoft Office Visio Professional 2007

· Microsoft Office Visio Standard 2007

Comment résoudre le problème ?

Vous pouvez appliquer la solution préconisée ci-dessous :

1. Fermer les classeurs Excel

2. Ouvrir l'explorateur Windows

3. Sélectionner le disque C:

4. Saisir dans la barre de recherche la chaîne de caractères suivante : *.exd

5. Lancer la recherche (attendre que la recherche soit terminée)

6. Plusieurs éléments portant l'extension exd vont être trouvés. Sélectionner et supprimer l'ensemble des éléments trouvés

7. Ouvrez de nouveau votre fichier Excel. Le problème devrait disparaître.

Sources d’informations

Si besoin vous trouverez des informations complémentaires sur les liens ci-dessous :

http://stackoverflow.com/questions/27497444/excel-2010-command-button-no-longer-activate-its-click-event

https://social.technet.microsoft.com/Forums/en-US/b8f0af82-0bb8-4799-aa62-1dbcbc5b7742/excel-2010-macros-does-not-work-after-updates-9dec2014?forum=excel

http://blogs.technet.com/b/the_microsoft_excel_support_team_blog/archive/2014/12/11/forms-controls-stop-working-after-december-2014-updates-.aspx

Dans Orchestrator, l’activité Run .NET Script permet d’exécuter des scripts dans différents langages (Powershell, VB .NET, JScript…) ce qui se révèle très utiles dans les nombreux cas où les activités apportées par les différents Integration Pack se révèlent insuffisantes pour effectuer les tâches dont vous avez besoin.

Cependant, il peut vite devenir compliqué de débugger ces scripts puisque l’activité Run .NET Script ne publie pas le résultat brut de leur exécution dans le databus : impossible alors de savoir où le script a échoué!

En revanche, ce que cette activité peut publier à l’aide de sa fonctionnalité Published Data, c’est le contenu de n’importe quelle variable que contient le script exécuté.

Il ne reste donc plus qu’à utiliser ce fonctionnement afin de stocker le résultat d’exécution du script dans une variable et de la publier via les Published Data.

Prenons l’exemple de ce script Powershell, un simple compteur qui ne présente pas d’intérêt autre que de produire une sortie sur plusieurs lignes :

for ($i=0; $i -le 10; $i++) {write-host $i}

Il suffit de l’encapsuler comme suit pour récupérer cette sortie dans Orchestrator :

$result = Powershell { for ($i=0; $i -le 10; $i++) {write-host $i} }

Puis de publier la variable result dans les Published Data :

La sortie du script est donc désormais publiée dans le databus.

On peut ensuite la récupérer dans un fichier texte à l’aide de l’activité Append Line, dans un évènement avec Send Event Log Message etc. Attention car dans ce second cas, un évènement sera créé pour chaque ligne si le mode Run Behavior > Flatten n’est pas utilisé!

Prenons l’exemple du fichier texte :

On voit bien que l’activité Append Line est appelée une fois par ligne contenue dans la variable result car le flatten n’est pas activé :

Et le résultat final :

Evidemment, cette astuce sera beaucoup plus utile pour des scripts réels!

A l’occasion du déploiement d’agents Linux à partir d’une infrastructure SCOM 2012 R2 UR4, un client a rencontré le problème suivant pour les serveurs exécutant la distribution CentOS 7 :

Failed during SSH discovery. Exit code: 2
Standard Output:
Standard Error: /etc/centos-release: line 1: syntax error near unexpected token `(‘
/etc/centos-release: line 1: `CentOS Linux release 7.0.1406 (Core) ‘
Exception Message:

Il reste possible de procéder à une installation manuelle de l’agent, mais cette solution est beaucoup moins pratique et plus longue.

Pour comprendre d’où provient cette erreur, il est nécessaire de comprendre au préalable que le processus de découverte d’un serveur Linux est réalisé par le script GetOSVersion.sh, disponible dans le dossier d’installation de SCOM : C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents

Lors de la découverte, ce script est copié et exécuté sur les serveurs à découvrir et tente principalement d’identifier la version de Linux exécutée par le serveur afin d’y déployer l’agent approprié.
Pour ce faire, il cherche à récupérer le contenu du fichier standardisé os-release qui contient des informations sur le système, à l’aide des lignes suivantes dans le cas d’un CentOS :

Le souci, c’est que la variable . $ReleaseFile pointe vers un fichier nommé centos-release qui contient, ô surprise, la ligne CentOS Linux release 7.0.1406 (Core) à la place des informations attendues au format TAG=VALUE.

Informations qui se trouvent par contre bien dans le fichier os-release… il ne reste alors qu’à corriger le script afin qu’il pointe vers le bon fichier, en remplaçant la ligne
. $ ReleaseFile
Par la ligne
. ${EtcPath}/os-release
Ce qui donne ce résultat :

Répétez cette opération sur tous les serveurs du Management Pool Linux et votre découverte ne devrait désormais plus poser de problème!

Attention! Cette modification n’est pas supportée par Microsoft et n’a pas été testée en profondeur, elle pourrait donc provoquer d’autres problèmes dans  des contextes différents! 
Par ailleurs, il y a de fortes chances que le fichier GetOSVersion.sh soit écrasé lors de l’installation de mises à jour futures. Il serait alors nécessaire de réappliquer la modification détaillée ici, si Microsoft n’apporte pas de correction.

Merci à Stéphane J. pour son implication sur cette problématique Linux assez spécifique!

Contexte

La faille POODLE (découverte par une équipe de Google fin Septembre) permet d’extraire depuis une transaction sécurisée en SSLv3 des informations secrètes (cookies, password) lors d’une attaque de type “Man in the middle”.

Suite à la découverte de cette faille, le protocole SSLv3 est maintenant obsolète, il est conseillé sur un serveur WEB, d’interdire l’utilisation de SSLv3 ce qui peut présenter des problèmes de compatibilité.

Explications

Lors d’une connexion à un site WEB, le navigateur et le serveur WEB vont négocier un protocole de chiffrement, le protocole négocié doit correspondre au protocole le plus à jour implémenté par le serveur et le client.

Bien qu’actuellement la grande majorité des navigateurs et des sites WEB implémentent des protocoles plus sécurisées que le SSLv3, il est possible que le protocole SSLv3 soit choisi par “fallback”. Il est également possible pour un utilisateur malveillant qui contrôlerait le réseau entre le client et le serveur de forcer la négociation d’un protocole antérieur au protocole le plus à jour implémenté par le client et le serveur afin d’en exploiter les failles.

Avec la faille POODLE touchant le SSLv3 et contrairement aux failles précédentes rencontrées sur SSLv3, aucun contournement n’est possible. Il faut donc bannir l’utilisation du protocole SSLv3.

C’est dans cette optique que les principaux navigateurs dont Firefox et Google Chrome, annoncent le retrait du support de SSLv3 sur leurs prochains produits.

Résolution sur IIS & ASP.NET

Sur un serveur web utilisant le framework .NET et qui est compatible avec TLS 1.0, il est possible de forcer l’utilisation d’algorithmes de cryptographie compatibles FIPS.

Cela se fait via l’activation de la stratégie locale située dans :

“Paramètres de sécurité locaux/Stratégies locales/Option de sécurité/Stratégie/Chiffrement Système”

Après cette modification les protocoles non compatibles FIPS (dont SSLv3) ne pourront être utilisés.

Par défaut, ASP.NET utilise des algorithmes non-compatibles avec FIPS, l’erreur 1309, visible dans le logs des évènements Web, est donc susceptible d’apparaitre :

Afin de modifier ce comportement, il faut spécifier au niveau du fichier Web.Config de l’application ASP.NET l’algorithme de cryptographie à utiliser.

Pour ce faire il faut dans la partie <system.web> du fichier Web.Config, ajouter la ligne suivante :

<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="3DES" decryption="3DES"/>

Sources :

http://support.microsoft.com/kb/911722

https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/

Contexte

Cet article a pour objectif de fournir les principales commandes PowerShell afin de créer un rapport, qui, exécuté avec une tâche planifiée, permet de générer automatiquement un rapport HTML envoyé par mail.

Dans cette série de deux articles, nous verrons comment créer deux scripts PowerShell qui permettent de remonter les principales informations pour :

• Une liste d’un ou plusieurs serveurs HYPER-V,
• Les machines virtuelles présentes sur un ou plusieurs serveurs HYPER-V.

Compatibilité :

Les scripts présentés dans cette série ont étés testés sur :

• HYPER-V pour Windows Server 2012R2
• HYPER-V pour Windows Server 2012

Dans ce premier article nous verrons les principales commandes à maitriser pour générer un rapport HTML à l’aide de PowerShell, ce prérequis est commun aux scripts de rapport des VMs ainsi qu’au script de rapport des Hyperviseurs.

Générer un rapport HTML en utilisant PowerShell

Afin de mieux nommer le fichier HTML l’idéal est de récupérer dans des variables la date et l’heure afin nommer le fichier de manière unique lors de chaque exécution :

Pour ajouter le code HTML depuis PowerShell, j’utilise la même variable tout au long du code dans laquelle le code HTML est ajouté à l’aide de l’operator “+=”. Une fois le script terminé, la variable contenant le code HTML est écrite vers le fichier HTML créé.

La ligne suivante permet de créer le fichier HTML vide sur lequel le code HTML vas être écrit :

Une fois le fichier HTML créé, il faut – comme pour toute page HTML – commencer par ouvrir les principales balises (html, head) ainsi que préciser l’encodage utilisé. On peut également en profiter pour définir le style désiré pour certaines balises types, ce qui évite d’avoir à préciser les mêmes éléments lors de l’utilisation de ces balises :

On peut remarquer l’utilisation de l’expression @" et de "@ qui nous permettent pour une variable au format string d’utiliser plusieurs lignes, ce qui permet d’avoir un code HTML correctement agencé.

Afin d’ajouter le contenu de la variable dans le fichier HTML, il faut utiliser la commande “Add-Content” :

Maintenant que le début du fichier HTML est créé, le script doit maintenant récupérer les informations que l’on souhaite faire apparaitre dans le rapport HTML (nous verrons ce point dans la partie suivante de ce post) dans des tableaux que l’on génère au fur et à mesure dans une boucle qui parcoure toutes les ressources (VM ou Hoster) à interroger afin de créer ce type de vue :

Le rapport présenté ci-dessus contient 4 tableaux des ressources qui sont regroupés dans un tableau pour des raisons d’affichage.

Afin de maitriser la taille en largeur des tableaux HTML des ressources, on commence par récupérer le nombre de tableau que l’on va générer que l’on divise par la taille du bloc. De cette manière, les tableaux des ressources auront la même taille :

La génération des tableaux des ressources est faite à l’aide d’une boucle qui va pour chaque machine de la liste récupérer ses informations puis créer un tableau pour chaque ressource. Avant la boucle, un tableau vide est créé, il faut bien veiller à fermer ce tableau après la sortie de la boucle :

Conclusion

Dans cet article, nous avons vu comment faire à l’aide de PowerShell pour générer des rapport HTML.

Le plus important est de bien maitriser l’ordre de génération du code HTML de manière à ce que les balises respectent les règles du format HTML.

Dans l’article suivant, nous verrons comment récupérer les principales informations pour une VM et un hôte HYPER-V afin de les ajouter aux tableaux composant le rapport HTML.