Mise en Oeuvre :

Installation sur l'infrastructure :

Pour réaliser l'installation de LAPS sur un serveur membre nous aurons besoin dans un premier temps d'un compte avec les droit Administrateur Local sur le serveur, puis de bénéficier des droits Admin du Schéma puis Admin du domaine ou Admin de ou des Unités d'Organisation en fonction de l'étendue sur laquelle vous souhaiter déployer LAPS. (Pour ma part je l'ai fait avec un compte "Admin du Domaine" sur lequel j'ai accordé les droits "Admin du schéma" le temps de l'installation).

L'installation se fait en suivant les étapes ci-dessous :

1. Installation de LAPS avec les composants Serveur.
2. Extension du schéma.
3. Attribution des droits.
   1. Droits pour les computers .
   2. Création des groupes de sécurité.
   3. Délégation des droits aux groupes de sécurité sur les OU.
4. Paramétrage des GPO
   1. Import des fichiers ADMX et ADML.
   2. Création et paramétrage de GPO.

Etape 1 : Installation de LAPS avec les composant serveur :

Le fichier msi fournit par LAPS permet d'installer les composants clients et serveurs, par défaut seul les composants clients sont installés, dans notre cas nous souhaitons déployer les composant serveurs nous sélectionnerons donc les "Management Tools".

Vous remarquerez la présence de 3 modules pour les "Management Tools" :

1. Fat Client UI : Soit l'interface utilisateur client lourd permettant de récupérer les mot de passe en clair dans l'AD
2. Powershell module : L'interface Powershell
3. GPO Editor Templates : Les ADMX

Etape 2 : Extension du schéma

Exécuter Powershell en tant qu'Administrateur.

# Import du module
Import-module AdmPwd.PS
# Update du schéma
Update-AdmPwdADSchema

Etape 3 : Attribution des droits.

Pour attribuer aux machines le droit de modifier leurs attributs exécutez :

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=Machines,DC=LAB,DC=INFO"

Pour créer les Groupes de sécurité afin de déléguer les droits (Lecture et Réinitialisation), vous avez deux options (en graphique via ADAC ou User & computers AD, ou avec Powershell, pour ma part ce sera Powershell).

# Création du Groupe Read_Laps
New-AdGroup -Name "Read_Laps" -SamAccountName "Read_Laps" -Description "Group For Read Permission" -GroupCategory Security -GroupScope Global -Path "OU=Groups,OU=IT,OU=Main,DC=LAB,DC=ORG"

# Création du Groupe Reset_Laps
New-AdGroup -Name "Read_Laps" -SamAccountName "Reset_Laps" -Description "Group For Reset Permission" -GroupCategory Security -GroupScope Global -Path "OU=Groups,OU=IT,OU=Main,DC=LAB,DC=ORG"

Nb: Le nom des groupes est un choix personnel, libre à vous de mettre autres choses.

Nous allons maintenant déléguer les droits sur une OU à l'aide des commandes suivantes :

# Permet d'attribuer le droit de lecture du mot de passe au Groupe "Read_Laps" sur l'OU "Main/IT/Computers"
Set-AdmPwdReadPasswordPermission -Identity "OU=COMPUTERS,OU=Main,DC=LAB,DC=ORG" -AllowedPrincipals Read_Laps –Verbose

# Permet d'attribuer le droit de changement du mot de passe au Groupe "Reset_Laps" sur l'OU "Main/IT/Computers"
Set-AdmPwdResetPasswordPermission –Identity "OU=COMPUTERS,OU=IT,OU=Main,DC=LAB,DC=ORG" –AllowedPrincipals Reset_Laps –Verbose

Nb : Le droit peut être déléguer sur l'ensemble du domaine, pour ma part seul les "Domain Admins" bénéficie de ce privilège.

Etape 4 : Paramétrage des GPO.

Par défaut, LAPS positionne les fichiers ADMX et ADML sur le poste local, si on veut les placer dans le SYSVOL de l’organisation, on ira donc récupérer :

• C:\Windows\PolicyDefinitions\AdmPwd.admx -> A copier dans le "%systemroot%\sysvol\domain\policies\PolicyDefinitions"
• C:\Windows\PolicyDefinitions\en-us\AdmPwd.adml -> A copier dans le "%systemroot%\sysvol\domain\policies\PolicyDefinitions\EN-US" (Option à répéter pour chaque langage de votre AD).

Nb: Si toutefois vous n'aviez pas les répertoires ci-dessus, il faudra les créer manuellement avec un compte ayant les droits.

Il ne nous reste plus qu'à déployer les stratégies de groupe pour définir le comportement de LAPS.

1. On ouvre donc "Group Policy Management" et on créé une nouvelle GPO (Dans cet Démo, on la nommera simplement "LAPS").
2. On accède aux nouveaux paramètres : Computer Configuration -> Policies -> Administrative Templates -> LAPS

C'est donc à partir de ces nouveaux paramètres que nous allons pouvoir activer ou inhiber LAPS et pouvoir agir sur les différentes politiques de sécurité :

• Intervalle de changement de mot de passe.
• Longueur et complexité du mot de passe.
• Définir le nom du compte Administrateur (Seulement si ce dernier à été renommé).

Activation de LAPS

Paramètre du nom de compte Administrateur : Ne pas configurer si le compte est celui par défaut.

Spécifications de longueur et complexité du mot de passe.

La configuration serveur est maintenant terminée.

Installation sur le client :

Comme par défaut le fichier msi n'installe que les composants client, il vous sera possible de scripter l'installation à l'aide de le commande : msiexec /i <emplacement>\LAPS.x64.msi /quiet

La partie client de LAPS est un CSE (Client Side Extension), soit une extension qui vient s’enregister auprès du service client de stratégies de groupe de Windows. Il s'agit donc bien d'une installation d'un composant de l'OS et non un nouveau service, que vous pourrez retrouver par défaut sous %programfiles%\LAPS\CSE\AdmPwd.dll

A chaque déclenchement du CSE, ce dernier :

• vérifie si le mot de passe est expiré à l'aide du dernier changement stocké dans l'attribut ms-Mcs-AdmPwdExpirationTime.
• S'il l'est, en génère un de manière aléatoire basé sur les politiques de sécurité définies par la GPO.
• Met à jour le mot de passe et l'inscrit en clair dans l'attribut ms-Mcs-AdmPwd et modifie l'attribut ms-Mcs-AdmPwdExpirationTime de l'objet Ordinateur dans l'Active Directory.

Voila la configuration est maintenant terminée, mappons la GPO et vérifions.

Vous êtes vous déjà posé la question "Mon parc informatique est il vulnérable?".

En terme de sécurité dans une grande majorité des cas la réponse est "Oui", mais alors pourquoi?

Grand nombre de personnes justifierons que le parc est à jour (Update, antivirus, firewall...), à cela je ne vous poserais que deux questions :

1. Le compte Admin Local est il désactivé sur toutes vos machines comme préconisé par Microsoft ? Si la réponse est non on peut déjà douter.
2. Le mot de passe du compte Admin Local des postes et/ou des serveurs est il différent sur chaque machine ? Si la réponse est non on à une faille de sécurité.

Envisageons simplement que  le mot de passe sur une de vos machines vient à être compromis, d'un coup, c'est l'ensemble de votre parc qui l'est et cela sans avoir besoin d'utiliser le compte Admin du domaine.

Une fois la première machine compromise il n'y a plus qu'a rebondir sur les autres pour pouvoir compromettre l'intégralité du parc.

Et si je vous disais qu'on pouvait gérer ce problème avec un outil développé par "Microsoft Consulting Services" et fournit gratuitement par Microsoft, laissez moi vous présenter LAPS.

Introduction à LAPS :

LAPS, qu'est ce que c'est?

LAPS pour "Local Admin Password Solution" est un outils permettant la gestion et le stockage du mot de passe Administrateur Local des machines du domaine : Postes clients et Serveurs membres.

Cette solution permet:

• De mettre à jour le mot de passe dans le contexte système et de l'envoyer au contrôleur de domaine à l'aide d'un composant client. Création aléatoire du mot de passe et transmission au contrôleur de domaine de manière crypté à l'aide de kerberos version 5 et Advanced Encryption Standard (AES).
• De stocker le mot de passe et sa durée de validité comme attribut de l'objet machine de l'Active Directory. ms-Mcs-AdmPwd et ms-Mcs-AdmPwdExpirationTime.
• Gérer le déploiement des paramètres de manière centraliser via les Stratégie de Groupes. Nom du compte, fréquence de changement, longueur et complexité.
• La récupération des mots de passe pour les utilisateurs habilités via une interface graphique ou Powershell. Par défaut seuls les "Admins du domaine" sont autorisés à accéder à ces informations mais il est possible de déléguer les droits sur un groupe.

Illustration à l'aide d'un schéma d'architecture de la solution :

Jusque là c'est sympa mais comment ça fonctionne?

Le coeur  de la solution LAPS est une extension d'un composant du client Stratégie de Groupe (CSE - Client Side Extension) qui pendant la mise à jour des Objets de Stratégies de Groupe, effectue et peut forcer les actions suivantes  :

1. Vérifier si le mot de passe Administrateur Local est expiré (Contrôle de la date de validité et de la configuration de la GPO).
2. Générer un nouveau mot de passe si l'ancien a expiré ou nécessite d'être changé avant expiration.
3. Valider que le nouveau mot de passe répond aux politiques de sécurité.
4. Envoyer le nouveau mot de passe à Active Directory et le stocker avec un attribut confidentiel dans l'objet ordinateur dans l'Active Directory.
5. Envoyer la prochaine date d'expiration du mot de passe à Active Directory et le stocker en tant qu'attribut dans l'objet ordinateur dans l'Active Directory.
6. Modifie le mot de passe du compte Administrateur local.

Il est possible de déléguer les droits suivants:

• Read Permission : Permet de lire le mot de passe depuis l'Active Directory, le client lourd LAPS ou avec Powershell par les utilisateurs autorisés. L'autorisation se fait par délégation de droits à des Groupes de sécurités (par défaut les "Admins du domaine").
• Reset Permission : Permet de soumettre une demande de changement de mot de passe depuis le client lourd LAPS ou avec Powershell.

Prérequis et OS supportés :

Prérequis :

Infrastructure :

• Active Directory : Windows Server 2003 SP1 ou ultérieur (L'attribut confidentiel n'est supporté qu'à partir du 2003 SP1 dans Active Directory)
• Ajout des attributs ms-Mcs-AdmPwd et ms-Mcs-AdmPwdExpirationTime (Action réalisé lors de l'installation).
• Restriction aux utilisateurs qui ne doivent pas accéder à l'attribut (retrait du All Extended Rights pour les groupes sensibles).
• Installation & paramétrage d'un ADMX.

•  Être Admin du Schéma le temps de l'installation (une Extension de Schéma est requise lors de l'installation)

Outils d'administrations :

• .NET Framework 4.0.
• Windows PowerShell 2.0 or ultérieur.

OS Supportés :

Clients : Windows 10 , Windows 8.1, Windows 8, Windows 7, Windows Vista avec le dernier Service Pack

Serveurs : Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008,  Windows Server 2003 avec le Service Pack 2 (mais plus supporté)

Note : Les machines Itanium ne sont pas supportées.

Problématique

Lors de l’installation d’un CU sur un serveur Exchange 2013, l’assistant d’installation vous demande de redémarrer en boucle sans jamais valider le redémarrage.

Solution

Si après un redémarrage le message d’erreur apparaît toujours, vous pouvez aller modifier la clé de registre suivante :

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations

Supprimer la valeur de cette clé et relancer l’assistant d’installation.

Comment Supprimer des KB dans son serveurs WSUS ?

Ce qui me déplait le plus dans un Serveur WSUS c'est de voir les KB dont je n'ai pas besoin (par Exemple les mises à jour pour Serveurs Itanium).

Toutes les mises à jours non désirées, remplacées ou expirées peuvent être déclinées, mais elles restent présentes en terme d'affichage.

Voyons comment les supprimer définitivement de la "WID", sans qu'elles ne reviennent après une synchronisation avec Windows Update.

Pour ce faire il faut donc:

1. Définir les KB que l'on souhaite supprimer (on va créer une variable).
2. Les supprimer à l'aide de Powershell.

1. Créer sa variable

Dans mon exemple je vais supprimer les KB déclinées et les Itanium.

$KB = $Wsus.GetUpdates()
$KBToDelete = $KB | Where-Object {($_.IsDeclined -eq $True) -or ($_.LegacyName -like "*Itanium*")}

2. Supprimer les KB

Maintenant supprimons les mises à jours associées à la variable.

# Check
$KBToDelete.count

# Action
$KBToDelete | Foreach-object {
  $Id = $_."Id"
  $KnowledgebaseArticles = $_."KnowledgebaseArticles"
  Write-Output "$KnowledgebaseArticles" | Add-Content C:\Temp\KBDeleteFromWid.txt
   $Wsus.DeleteUpdate($Id.UpdateId.ToString())
   }

# New Check
$KB = $Wsus.GetUpdates()
$KBToDelete = $KB | Where-Object {($_.IsDeclined -eq $True) -or ($_.LegacyName -like "*Itanium*")}
$KBToDelete.count

Et voila, comme ça je garde une vue relativement "propre" dans mes WSUS.

Si jamais vous souhaitiez de nouveau obtenir un KB supprimée, il faudra faire un import manuel depuis le serveur WSUS.

Import Manuel de mises à jour

1. Sur le serveur WSUS développez "Update Services".
2. Sur "Updates" faites un clic droit "Import Updates...".
3. Vous serez redirigé vers la pages du Catalogue Microsoft®Update.
4. Sur le Catalog Update, il faudra rechercher le numéro de KB que vous souhaitez importer.
5. Sélectionnez votre KB, faites « ajouter » (répétez l'opération de recherche et d'ajout au Panier autant de fois que de KB à importer), puis aller dans votre panier.
6. Cochez "Importer directement dans Windows Server Update Services" et faites « importer ».

Introduction

Il est primordial pour une entreprise de bien gérer, exploiter et simplifier la gestion de ses logs applicatifs. Une application peut générer plusieurs type de log, fichier plat, événement Windows ou dans une table d'une base de données. Il existe des outils pour gérer ses logs, Splunk, ELK Elastics Search, .... Nous allons dans ce blog , mettre en place une infrastructure ELK pour gérer les logs provenant de plusieurs source de fichiers plats. Les outils mis en place sont représentés par le schéma suivant: 

Présentation des composants

ELK - Elastic Search vient avec 4 composant principaux : 

• KIBANA - Le frontal web d'administration, consultation de log en sélectionnant un index, création/visualisation des indicateurs 
• Elastic search - base de données NOSQL pour le stockage des données de log dans des indexes 
• Logstash - collecter, transformer et parse les logs à Elastic search
• Beats - voir ci-dessous

Il existe plusieurs modules dans la famille BEATS  à mettre en place et qui dépend de la source et type de log, les 3 principaux sont : 

• filebeat - pour des logs dans des fichiers plat
• winlogbeat - logs provenant des événement Windows 
• packetbeat - protocols réseau, quantité des données transférées sur un serveurs ou sur le réseau

Installation des composants

NB: JAVA JRE est nécessaire pour faire fonctionner la suite ELK, assurer que JAVA a été installé.Vous obtiendrez les dernières versions des binaires directement du site elastic search: https://www.elastic.co/fr/products

1) Elastic Search - base de données NoSQL

L’installation des binaires se fait en dézippant le fichier elasticsearch-5.6.3.zip dans le répertoire d’installation souhaitée. Utiliser l'utilitaire NSSM pour installer Elastics Search comme un service windows. 

Sélectionner "Installer le service" pour installer le service Elastic Search.

2) Logstash

L’installation des binaires se fait en dézippant le fichier logstash-5.6.3.zip dans le répertoire d’installation souhaitée.

Installer le service logstash comme un service windows:

Sélectionner "Installer le service" pour installer le service Logstash.

3) Filebeat

L’installation des binaires se fait en dézippant le fichier filebeat-5.6.3.zip dans le répertoire d’installation souhaitée.

Installer le service filebeat comme un service windows en utilisant l'utilitaire NSSM.

4) Kibana

L’installation des binaires se fait en dézippant le fichier kibana-5.6.3.zip dans le répertoire d’installation souhaitée. 

Installer le service Kibana comme un service windows en utilisant l'utilisateur NSSM.

Modifier le fichier kibana.yaml comme indiqué ci-dessous: 

server.port: 80
server.host: "SERVER IP"
server.name: "SERVER_NAME"
elasticsearch.url: "http://SERVER_NAME:9200"

NB: Logstash, Elastic Search et Filebeats possèdent chacun des fichiers de configuration, dans cette installation nous allons tout laisser par défaut. 

Tests:

Redémarrer tous les services et lancer l’url du site dans l’ordre ci-dessous:

• ELK – Elastic Search
• ELK – Filebeat
• ELK – Logstash
• ELK – Kibana

Accéder au portail via localhost http://localhost:port  comme indiqué ci-dessous:

Nombre de clients étudient actuellement la migration de leur environnement SCOM 2012 (R2), qui, rappelons-le, a atteint la fin de sa période de support mainstream en juillet 2017.

Il y a actuellement deux possibilités : passer à la version 2016 sortie il y a déjà presque 2 ans ou opter directement pour la version 1801 sortie il y a moins de 2 mois ; sachant qu’il est possible de migrer depuis la version 2012 R2 directement vers ces deux versions, qu’il s’agisse de migration side by side ou in-place.

Commençons par rappeler que ces deux versions ne se distinguent pas par leur architecture ni leur prérequis, ils sont strictement identiques.

La version 1801 étant plus récente, elle contient bien entendu quelques fonctionnalités supplémentaires (et non des moindres, à l’image de la console web enfin 100% html5 et de ses nouveaux dashboards) ; mais ce n’est finalement pas ce qui la différencie fondamentalement de la version 2016. Pour un aperçu détaillé des nouveautés apportées par ces deux versions, technet reste la source la plus appropriée : What’s new in SCOM 2016 et What’s new in SCOM 1801 .

Non, ce qui différencie réellement ces deux versions, c’est plutôt que la sortie de la version 1801 marque la scission en deux branches distinctes de la suite System Center : la Long-Term Service Channel (LTSC) et la Semi-Annual Channel (SAC) ; reprenant ainsi le modèle inauguré avec Windows et SCCM Current Branch.

Ces deux termes désignent le mode de release du produit, autrement dit sa fréquence de parution, sa durée de support et les fonctionnalités qu’il intègre.

Afin de prendre la décision la plus renseignée possible, voici un tour d’horizon de ce que nous savons de ces deux branches… mais aussi (et surtout) de ce que nous ne savons pas encore !

LTSC

Ce mode de release est dans la continuité de ce qui était connu jusqu’ici :

• Une nouvelle version majeure tous les 3 ans environ, qui devrait suivre les versions LTSC de Windows
• Une durée de support de 5+5 ans (mainstream+étendu)
• Des patchs tous les 3-6 mois visant principalement des corrections de bug et de sécurité (Update Rollups)
• Peu ou pas de nouvelles fonctionnalités pendant la durée de vie du produit

Il n’existe pas encore réellement de release LTSC de System Center (bien qu’on puisse considérer que la version 2016 en est une), mais Microsoft a profité de l’annonce de Windows 2019 pour confirmer la sortie de System Center 2019, qui sera donc la première véritable LTSC (https://cloudblogs.microsoft.com/windowsserver/2018/03/20/introducing-windows-server-2019-now-available-in-preview/).

Il n’est donc pas possible pour le moment d’anticiper avec certitude les choix que Microsoft fera pour cette version, mais certaines suppositions peuvent être faites avec un minimum de fiabilité. Chaque nouvelle version LTSC devrait:

· Intégrer les nouvelles fonctionnalités parues dans les versions SAC précédentes

· Nécessiter d’en passer par une migration pour réaliser le changement de version, qu’elle soit in-place ou side by side, comme pour le passage de SCOM 2012 à 2016 par exemple.

Le mode d’installation des patchs (Update Rollups) devrait rester similaire à ce qui est connu actuellement avec SCOM 2012 et 2016 et devrait donc nécessiter un certain nombre d’étapes manuelles, sans toutefois entrainer d’indisponibilité de la plateforme.

Enfin, s’il semble acquis que la mise à jour vers la future LTSC 2019 sera supportée depuis la version 2016, rien n’indique qu’il sera possible de passer d’une version SAC (1801 et ultérieures) à la version LTSC 2019 ; ni qu’il sera possible de passer de la version LTSC 2019 à une version SAC ultérieure.

Les versions LTSC sont donc à privilégier lorsque la stabilité de l’infrastructure et la durée du support sont les points les plus importants de votre choix.

SAC

Dans ce mode, Microsoft annonce :

• Une mise à jour tous les 6 mois environ
• Une durée de support limitée aux 3 dernières versions, donc d’une durée d’environ 18 mois
• L’ajout régulier de nouvelles fonctionnalités, probablement à chaque mise à jour

Attention : des mises à jour régulières signifient également autant de chances en plus de voir disparaitre des fonctionnalités ou le support de systèmes dépréciés.

La première version SAC est ainsi nommée « SCOM 1801 » en référence à sa date de sortie (Janvier 2018).

On peut donc supposer que la prochaine mise à jour apparaitra en juin-juillet 2018, mais Microsoft n’a pas encore communiqué dessus et n’a donc pas non plus communiqué sur la forme que prendrait cette mise à jour ni sur son mode d’installation.

Il est cependant là aussi possible de faire quelques suppositions à partir des éléments déjà disponibles :

• SCOM 1801 n’intègre pas de mécanisme de mise à jour simplifiée « in-console » (à la manière d’un SCCM depuis son passage en SAC, cf. https://docs.microsoft.com/fr-fr/sccm/core/servers/manage/install-in-console-updates ).
• Il serait surprenant qu’une mise à jour bi-annuelle nécessite un processus de type migration complète (in-place ou side by side)

On peut donc s’attendre à ce que le mécanisme de mise à jour vers la prochaine version SAC soit semblable à ce qui existe actuellement pour l’installation des Update Rollups ; autrement dit un processus par définition encore assez manuel mais n’entrainant pas d’indisponibilité de la plateforme.

On peut aussi imaginer qu’un mécanisme « in-console » similaire à celui de SCCM apparaitra à l’avenir, mais il s’agit d’une pure spéculation : Microsoft n’a aucunement communiqué à ce sujet, ni officiellement ni via les demandes de la communauté (https://systemcenterom.uservoice.com/forums/293064-general-operations-manager-feedback/suggestions/33067480-provide-capability-to-apply-update-rollups-from-co )

Par ailleurs, aucune information n’est disponible concernant la possibilité de passer d’une release SAC à une future release LTSC.

Les versions SAC sont donc à privilégier lorsque l’ajout régulier de nouvelles fonctionnalités et le support rapide des nouvelles technologies constituent les points les plus importants, tout en restant vigilant : un cycle de mise à jour rapide peut également entrainer la fin du support de certaines fonctionnalités et technologies à brève échéance (par exemple l’abandon de la supervision d’une ancienne version de Windows, ou l’obligation de mettre à jour la base de données).

Alors, on choisit quoi ?

Comme souvent il n’y a pas de bonne réponse universelle ; d’autant plus ici en raison des nombreuses incertitudes qui entourent encore le futur des 2 branches.

Au final, le choix peut se résumer à cette question : désirez-vous toujours disposer des dernières innovations du produit (ce qui n’est pas un luxe vu le retard qu’il accumule dans certains domaines) au prix d’une potentielle instabilité et au risque de voir disparaitre le support de certaines fonctionnalités ; ou préférez-vous la stabilité et la sécurité apportées par des release plus espacées et plus matures ?

Etant donné la vitesse de l’évolution des technologies (et mon attrait pour les nouvelles fonctionnalités), mon cœur balance évidemment vers la branche SAC. Mais votre point de vue pourrait être tout à fait opposé, et vous pourriez tout aussi bien décider de passer en version 2016 par sécurité, ou d’attendre la sortie en fin d’année de la version LTSC 2019…

Contexte

Rajouter quelques PCs portables dans une salle qui ne peut plus accueillir de prises réseaux filaires.

D'abord configurer la connexion WiFi sur un PC portable, puis l’exporter avec la commande

netsh wlan export profile key=clear c:\

 C:\Users\Administrateur>netsh wlan export profile key

 Le profil d'interface « SSID » est enregistré dans le fichier « .\Wi-Fi-SSID.xml »

La clé apparaît en clair sauf avec la commande "netsh wlan export profile"

On crée la gpo sous configuration ordinateur>Paramètres Windows>paramètres de sécurité>Stratégie de réseau sans fil>nouvelle stratégie

On renseigne le SSID et mot de passe, connexion automatique et préférée, mais je change pour l’occasion le nom à diffuser en «Accès-SF »

Je lie la stratégie à une salle donnée.

Le SSID d’origine apparaît en non disponible alors que la connexion Acces-SF est active et connectée.

Les utilisateurs doivent se connecter au moins une fois en filaire sur le poste pour appliquer la stratégie.

Ces 3 derniers mois, j’ai reçu de plusieurs sources différentes une question concernant la disparition « soudaine » des tâches dans la console lourde SCOM :

Autre point commun, ce problème ne concernait à chaque fois que des consoles installées sur des postes utilisateurs, ou publiées sur Citrix. Les tâches étaient par contre bien présentes sur les consoles installées sur les Management Servers, et dans la console Web.

Dans un premier temps, cela me fit penser à une console cliente n’ayant jamais reçu de mise à jour (update rollup) ; c’est un problème que j’avais déjà rencontré il y a quelques années, mais il s’avéra rapidement que cela n’était pas le cas ici.

Une recherche sur le web en me basant sur ces symptômes m’a ensuite orienté vers une quelques articles de blogs assez anciens, indiquant une incompatibilité connue lors de la mise à jour de Savision LiveMaps v1 à v7/8 : https://www.savision.com/knowledge-base/troubleshooting/missing-console-tasks-operations-console-upgrade-live-maps-v78/

Cela semblait cependant assez peu vraisemblable, ces environnements étant beaucoup plus récents. Il me fut d’ailleurs rapidement confirmé qu’ils n’utilisaient de toute facon pas LiveMaps…

Cette piste mis cependant la puce à l’oreille d’un de ces utilisateurs : le problème semblait avoir débuté lors de l’installation de la dernière version (4.0) du management pack HP Oneview, sortie en décembre 2017.

Sa suppression confirma rapidement qu’il était bien le coupable, mais il n’était pas envisageable de se satisfaire de ce contournement, ce management pack étant très utilisé.

Restait donc à trouver où se situait exactement le problème.

Une analyse des journaux d’événements Windows sur les postes concernés par le problème apporta un indice important, puisque l’événement suivant apparaissant dans le journal Application à chaque lancement de la console SCOM:

Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information. : System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
   at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
   at System.Reflection.Assembly.GetTypes()
   at Microsoft.EnterpriseManagement.Presentation.DeclaredAssemblyLoader.LoadModuleCatalogFromAssembly(IModuleCatalog bootstrapperCatalog, ModuleCatalog catalog, Assembly assembly)
   at Microsoft.EnterpriseManagement.Presentation.DeclaredAssemblyLoader.CreateModuleCatalog(IEnumerable`1 assemblies)
   at Microsoft.EnterpriseManagement.Presentation.DeclaredAssemblyLoader.LoadInternal(IEnumerable`1 assemblies)
   at Microsoft.EnterpriseManagement.Presentation.DeclaredAssemblyLoader.Load(DeclaredAssembly assembly)
   at Microsoft.EnterpriseManagement.Monitoring.Components.ComponentRegistry.<>c__DisplayClass3e.<GetAssemblies>b__3c(DeclaredAssembly declaredAssembly)
   at System.Reactive.Linq.Observable.<>c__DisplayClass413`2.<>c__DisplayClass415.<Select>b__412(TSource x)

Cet événement indique que lors de son lancement, la console échoue à charger un ou plusieurs composants dll ; ce qui pourrait facilement laisser à penser que l’installation du MP Oneview ajoute des dépendances à la console SCOM, qui sont absentes des postes clients.

Un incident ouvert auprès du support HP confirma cette dépendance, ainsi que le contournement qui s’imposait : installer la console OneView sur tous les postes disposant de la console SCOM.

Problème réglé !

Contexte

Suite à un reboot, l’exécution d’un data collector set créé depuis Perfmon est interrompue.

La console PerfMon permet uniquement de planifier le lancement d’un DCS en fonction de dates spécifiques et non en fonction d’un évènement :

Ce post explique comment automatiquement lancer un Data Collector Set à chaque démarrage du serveur.

Résolution

Depuis le Task Scheduler naviguer vers “Library -> Microsoft -> Windows –> PLA” :

Sélectionner le DCS souhaité puis ajouter un trigger du type “At system startup” :

Contexte

Sur une même machine Windows, il est impossible de réaliser plus de 3 sysprep, au bout de la 4eme tentative, l’utilitaire sysprep affiche l’erreur suivante :

Microsoft recommande d’utiliser une image d’un système “sysprepé” afin de contourner cette limite.

Cette limite a été mise en place afin que sysprep ne soit pas utilisé pour réinitialiser la période de grâce de 30 jours que Microsoft fourni pour activer la licence.

Résolution

Pour sysprep une même machine plus de trois fois, les étapes suivantes doivent être réalisées :

1. Depuis l’éditeur de registre,

Depuis la l’entrée “HKEY_LOCAL_MACHINE\System\Setup\Status\SysprepStatus”, modifier la valeur de la clé “CleanupState” à 2 et la valeur de la clé “GeneralizationState” à 7 :

Depuis la l’entrée “HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\SoftwareProtectionPlatform”, modifier la valeur de la clé “SkipRearm” à 1 :

2. Depuis un command prompt lancé en tant qu’administrateur,

Exécuter les commandes suivantes :

msdtc -uninstall
msdtc -install

3. Depuis le répertoire “C:\Windows\System32\Sysprep” supprimer le dossier “Panther” :