Contexte

Lors d’un renouvellement de certificat WEB sur une instance SSRS, le mapping du nouveau certificat échoue avec l’erreur suivante :

Microsoft.ReportingServices.WmiProvider.WMIProviderException: An SSL binding already exists for the specified IP address and port combination. The existing binding uses a different certificate from the current request. Only one certificate can be used for each IP address and port combination. To correct the problem, either use the same certificate as the existing binding, or remove the existing SSL binding and create a new binding using the certificate of the current request.

Explication

Le message d’erreur précise que la combinaison IP:Port est déjà mappée à un certificat existant (celui que l’on tente de renouveler).

La commande suivante permet de visualiser le binding existant :

netsh http show sslcert

On remarque que le certificat que l’on tente de renouveller est mappé à la combinaison IP:Port suivante : [::]:443

Résolution

A l’aide de la commande précédemment citée, récupérer la combinaison IP:Port utilisée par le certificat que l’on tente de renouveler, puis supprimer le mappage à l’aide de la commande suivante :

netsh http delete sslcert ipport=[::]:443

Contexte

Depuis une console lancée en tant qu’administrateur du domaine il est impossible de supprimer une zone DNS existante, une erreur de type “AccessDenied” est retournée :

Explication

En investiguant sur la cause de cette erreur, on remarque qu’une ACE refuse au groupe Tout le Monde de supprimer cet objet :

Cette ACE est en fait créée automatiquement lorsque la protection contre la suppression accidentelle est activée.

Résolution

Après la suppression de cette entrée, il est possible de supprimer l’objet sans erreurs.

Contexte

La mise en miroir des bases de données est une solution de haute-disponibilité fournie par SQL Server depuis la version 2005. Cette fonctionnalité s’implémente au niveau de chaque base de donnée.

L’avantage de cette solution est de disposer d’une base de donnée active en tout temps, ce qui permet de réaliser des maintenances sur un serveur sans interrompre l’accès aux bases utilisées par des application clientes.

Cette fonctionnalité sera supprimée dans une prochaine version de Microsoft SQL Server. Évitez d'utiliser cette fonctionnalité dans de nouveaux travaux de développement, et prévoyez de modifier les applications qui utilisent actuellement cette fonctionnalité. Utilisez à la place Groupes de disponibilité Always On.

Cause

Voici les principales causes provoquant une interruption de la replication Mirroring :

• Les serveurs partner (+ eventuellement witness) ne communiquent pas correctemment,
• Erreur d’espace disque sur l’un des serveurs partner,
• Changement du recovery model sur le serveur principal (le mirroring requière le recovery model Full).

Résolution

La commande suivante exécutée sur l’un des serveur partner permet de rétablir la réplication :

ALTER DATABASE DATABASE SET PARTNER RESUME

Contexte

Dans Office 365 lorsque vous activez une fonctionnalité qui déclenche un mail automatique (exemple : activation de l’UM, activation du PSTN calling…) le mail est rédigé dans la langue du tenant et non dans celle de l’utilisateur.

Explications et solution

Par défaut l’ensemble des mails envoyés automatiquement utilise la langue sélectionnée lors de la création du tenant. Donc si votre tenant a été créé en Français l’ensemble des mails sont envoyé en Français.

Pour changer la langue, en anglais par exemple, il faut que l’utilisateur possède l’attribut PreferredLanguage de renseigné sur son compte Active Directory. Pour l’anglais il est possible de mettre “EN-US” ou “EN-GB”.

La liste des code possibles est disponible au lien suivant https://technet.microsoft.com/en-us/library/ee825488.aspx.

Une fois la valeur modifiée (et après avoir effectué une synchronisation AzureADConnect) le mail envoyé est en anglais !

Script de modification de l’attribut PreferredLanguage dans l’AD

Si vous souhaitez modifier en masse l'ensemble des utilisateurs vous pouvez utiliser le script PowerShell ci-dessous.

$users = Get-ADUser -Filter * -SearchBase "DC=MONDOMAINE,DC=COM" -SearchScope Subtree
$actual=1
$total = $users.count
foreach($user in $users)
{ 
   $sam = $user.SamAccountName
   Write-Progress -Id 1 -Activity ("Working...Please wait") -PercentComplete ($actual / $total * 100) -Status ("Working on {0} - {1} / {2}" -f $sam, $actual, $total)
   Set-ADUser $sam -add @{PreferredLanguage="EN-GB"}
   $actual++
}

Tous les admins SCOM vous le diront : créer des nouvelles règles dans la console classique peut s’avérer terriblement frustrant, en particulier par son manque de flexibilité et de liberté.

Un exemple particulièrement récurrent est l’impossibilité d’utiliser autre chose que le Visual Basic pour créer des règles ou moniteurs scriptés, alors qu’il est parfaitement possible d’utiliser Powershell en passant par des outils tiers (MP Author de Silect, voire VisualStudio).

Une première tentative de simplifier les choses avait été réalisée par Wei Lim, avec un management pack qui apportait un wizard permettant la création de moniteurs en powershell directement dans la console SCOM : https://blogs.msdn.microsoft.com/wei_out_there_with_system_center/2015/07/09/opsmgr-new-sample-wizard-to-create-powershell-monitors-in-the-ops-console/

Cela restait cependant assez limité, il n’était par exemple pas possible de passer de paramètres aux scripts au début (ce qui fut corrigé dans une release ultérieure) et seule la création de moniteurs à 2 états était possible.

Depuis peu, SquaredUp (société bien connue pour son excellente console web éponyme, nous en reparlerons surement un jour) propose également un management pack gratuit, qui apporte enfin à la console SCOM les fonctionnalités que nous étions en droit d’attendre : création de moniteurs à 2 et 3 états, de tous types de règles, de tâches… en powershell, à l’aide de wizards fort bien concus !

Le Management Pack est disponible ici : https://squaredup.com/free-powershell-management-pack/

Description

Sophos Central vous permet de gérer les politiques de sécurité et d’administrer plusieurs produits depuis une seule interface Web. Aucune installation ou déploiement de serveurs de gestion ne sont requis. Vos serveurs et appareils se connecteront directement à Sophos Central pour recevoir les nouveaux paramètres, envoyer des alertes et partager l’intelligence contextuelle de sécurité.

Installation

Pour pourvoir manager vos appareils il faut dans un premier temps ajouter les comptes utilisateurs dans la console Sophos Central. Pour ce faire il existe deux méthodes soit :

• Ajouter les comptes à la manuellement, en remplissant les informations suivantes :

• Synchroniser les comptes Active Directory de votre entreprise avec l’outil « AD Sync Settings/Status ».

Nous allons nous attarder sur la deuxième méthode.

Tout d’abord il faut se rendre dans l’onglet « Global Settings » et télécharger l’outil.

Lancer l’exécutable sur un Contrôleur de Domaine puis un assistant va apparaître pour configurer la synchronisation.

Mettre votre compte Sophos Central.

Cocher l’option “SSL” puis remplir les informations suivantes.

Note : utiliser un compte de service pour effectuer la synchronisation.

Choisir le ou les domaines puis les “OU” à synchroniser.

Il ne reste plus qu’a définir quand s’effectuera la synchronisation.

Une fois fini cliquer sur « Finished » et l’utilitaire ce synchronisera à l’heure que vous avez indiquez. Pour lancer une première synchronisation il faut cliquer sur « preview and sync ».

Les comptes sont maintenant ajoutés dans Sophos Central.

La dernière étape est d’installer les agents sur les appareils clients. Une des méthodes est de leurs envoyer un mail d’instruction expliquant les différentes étapes d’installation depuis la console Sophos.

Configuration

Dans l’onglet “Endpoint Protection” puis “Policies” vous pouvez configurer les règles de sécurité des utilisateurs.

Il ne reste plus qu’a créer vos règles en fonction de vos besoins.

Information :

Pour plus d’information concernant la configuration, je vous invite à consulter le lien suivant : http://docs.sophos.com/sophos-cloud/help/fr-fr/PDF/scloud_hfra.pdf

Lors de la finalisation d’une migration side by side SCOM 2007 vers SCOM 2012 R2, j’ai rencontré un problème assez inattendu : il ne restait alors plus que quelques agents Windows 2003 à déployer et quelques autres à mettre à jour avec le dernier UR, et je n’anticipais pas de problème particulier dans cette phase déjà réalisée à maintes reprises sur d’autres serveurs de cet environnement ainsi que sur d’autres environnements.

J’ai donc eu la mauvaise surprise de constater que ces agents s’arrêtaient dès leur démarrage, parfois sans aucun message d’erreur (arrêt « propre » matérialisé par les événements 103 puis 101), parfois avec un message d’erreur assez peu parlant (événement 1000 après l’événement 103) :

Faulting application healthservice.exe, version 7.1.10292.0, stamp 585161d0, faulting module unknown, version 0.0.0.0, stamp 00000000, debug ? 0, fault address 0x000c9ba0.

J’ai alors décidé de prendre une trace de l’agent, afin d’obtenir un diagnostic plus poussé (cf. https://blog.piservices.fr/post/2017/09/30/SCOM-Prendre-une-trace-de-lagent1).

Fort heureusement le problème était très simple à reproduire (un simple démarrage de l’agent…), et m’a permis d’obtenir l’erreur suivante :

Unable to create self-signed certificate : -2146893816(NTE_BAD_ALGID).

L’agent échoue donc à créer un certificat auto-signé lors de son démarrage, et plante dans la foulée.

Mais pourquoi chercherait-il à générer un certificat ? Comme le précise Stefan Roth dans cet article très détaillé (https://stefanroth.net/2016/03/02/scom-how-data-is-encrypted/), ce certificat est utilisé lorsque le Management Server transmet un RunAs Account à un agent afin d’apporter un niveau de chiffrement supplémentaire.

Ce certificat est donc créé lors du premier démarrage de l’agent, ainsi que lorsqu’il expire (sa durée de vie est d’un an) :

Nous constatons sur la capture ci-dessus que le certificat est bel et bien présent dans le magasin.

Pourquoi l’agent cherche-t-il a le régénérer, et pourquoi échoue-t-il ?

La réponse à la première question se trouve (de façon assez peu claire il est vrai) dans les release notes de l’UR12 de SCOM 2012 R2 :

• SHA2 support for certificates:  SHA1 is deprecated for the System Center 2012 R2 Operations Manager Agent and SHA2 is now supported.

Autrement dit, le certificat auto-signé de l’agent est maintenant signé avec l’algorithme SHA2 (SHA256RSA) et non plus avec SHA1.

Tant mieux pour la sécurité, SHA1 est aujourd’hui considéré comme déprécié et ne devrait plus être utilisé.

La réponse à la seconde question se trouve encore une fois chez Microsoft : Windows 2003 (et par extension Windows XP) ne supporte pas les algorithmes de la famille SHA2 sans un hotfix qui n’a jamais été intégré aux mises à jour régulières, comme l’indique la KB suivante : http://support.microsoft.com/kb/938397

Une fois le hotfix installé et le serveur redémarré, on constate que l’agent démarre sans encombre et qu’un certificat signé en SHA256 est généré :

Et voilà, problème réglé !

Il peut arriver qu’un agent SCOM rencontre un problème (plantage, supervision qui échoue…) sans raison identifiable dans les journaux d’événement.

Dans ce cas, il reste une dernière solution : prendre une trace de debug.

Les outils le permettant sont disponibles nativement sur tous les serveurs où l’agent est installé.

Préparation

Dans un premier temps, il est nécessaire de se connecter au serveur où se trouve l’agent pour lequel vous souhaitez réaliser une trace puis localisez le dossier d’installation de l’agent, normalement C:\Program Files\System Center Operations Manager\Agent\Tools pour un SCOM 2012 ou C:\Program Files\Microsoft Monitoring Agent\Agent\Tools pour un SCOM 2012 R2.

Ouvrez une ligne de commande cmd.exe en mode administrateur, puis rendez vous dans le dossier en question et exécutez la commande StopTracing.cmd afin de vous assurer que toutes les traces préalables sont bien arrêtées.

Profitez-en pour relever le dossier où se trouvent les logs, indiqué à la ligne Log Filename (ici C:\Windows\Logs\OpsMgrTrace ) et supprimez tous les fichiers qu’il contient, afin de faire place nette pour la nouvelle trace à venir.

Prise de la trace

Toujours depuis votre invite de commande, tapez StartTracing.cmd VER (respectez bien les majuscules pour VER) puis attendez que le problème se reproduise ou, mieux, essayez de forcer sa reproduction : plus la trace durera longtemps et plus elle sera longue à traiter et à analyser…

Une fois le problème survenu, arrêtez la trace (toujours avec Stoptracing.cmd).

Traitement et analyse de la trace

Les fichiers ETL de trace sont, à la base, totalement illisibles : il faut donc les convertir en quelque chose que vous puissiez analyser.

Pour ce faire, lancez la commande formattracing.cmd. Elle peut être assez longue à s’exécuter selon la durée de votre trace.

Une fois terminée, vous constaterez que des fichiers .log ont été créés dans le dossier de logs. Ce sont eux que vous allez pouvoir ouvrir pour tenter de comprendre les soucis rencontrés par l’agent.

Mais même s’ils sont lisibles dans un notepad, ils restent assez peu digestes :

Vous pouvez utiliser l’outil CMTrace, issu du toolkit de SCCM ( https://www.microsoft.com/en-us/download/details.aspx?id=50012 ), pour obtenir un résultat un peu plus facilement exploitable :

Ensuite, à vous de jouer et de repérer les lignes avec des erreurs (normalement signalées par une balise [ERROR]) pour identifier l’origine de votre problème.

Lors de la finalisation d’une migration side by side SCOM 2007 vers SCOM 2012 R2, j’ai rencontré un problème assez inattendu : il ne restait alors plus que quelques agents Windows 2003 à déployer et quelques autres à mettre à jour avec le dernier UR, et je n’anticipais pas de problème particulier dans cette phase déjà réalisée à maintes reprises sur d’autres serveurs de cet environnement ainsi que sur d’autres environnements.

J’ai donc eu la mauvaise surprise de constater que ces agents s’arrêtaient dès leur démarrage, parfois sans aucun message d’erreur (arrêt « propre » matérialisé par les événements 103 puis 101), parfois avec un message d’erreur assez peu parlant (événement 1000 après l’événement 103) :

Faulting application healthservice.exe, version 7.1.10292.0, stamp 585161d0, faulting module unknown, version 0.0.0.0, stamp 00000000, debug ? 0, fault address 0x000c9ba0.

J’ai alors décidé de prendre une trace de l’agent, afin d’obtenir un diagnostic plus poussé (cf. https://blog.piservices.fr/post/2017/09/30/SCOM-Prendre-une-trace-de-lagent ).

Fort heureusement le problème était très simple à reproduire (un simple démarrage de l’agent…), et m’a permis d’obtenir l’erreur suivante :

Unable to create self-signed certificate : -2146893816(NTE_BAD_ALGID).

L’agent échoue donc à créer un certificat auto-signé lors de son démarrage, et plante dans la foulée.

Mais pourquoi chercherait-il à générer un certificat ? Comme le précise Stefan Roth dans cet article très détaillé (https://stefanroth.net/2016/03/02/scom-how-data-is-encrypted/), ce certificat est utilisé lorsque le Management Server transmet un RunAs Account à un agent afin d’apporter un niveau de chiffrement supplémentaire.

Ce certificat est donc créé lors du premier démarrage de l’agent, ainsi que lorsqu’il expire (sa durée de vie est d’un an) :

Nous constatons sur la capture ci-dessus que le certificat est bel et bien présent dans le magasin.

Pourquoi l’agent cherche-t-il a le régénérer, et pourquoi échoue-t-il ?

La réponse à la première question se trouve (de façon assez peu claire il est vrai) dans les release notes de l’UR12 de SCOM 2012 R2 :

• SHA2 support for certificates:  SHA1 is deprecated for the System Center 2012 R2 Operations Manager Agent and SHA2 is now supported.

Autrement dit, le certificat auto-signé de l’agent est maintenant signé avec l’algorithme SHA2 (SHA256RSA) et non plus avec SHA1.

Tant mieux pour la sécurité, SHA1 est aujourd’hui considéré comme déprécié et ne devrait plus être utilisé.

La réponse à la seconde question se trouve encore une fois chez Microsoft : Windows 2003 (et par extension Windows XP) ne supporte pas les algorithmes de la famille SHA2 sans un hotfix qui n’a jamais été intégré aux mises à jour régulières, comme l’indique la KB suivante : http://support.microsoft.com/kb/938397

Une fois le hotfix installé et le serveur redémarré, on constate que l’agent démarre sans encombre et qu’un certificat signé en SHA256 est généré :

Et voilà, problème réglé !

Problématique

Après de l’ajout d’une boite mail OVH en IMAP et lors de la synchronisation de celle ci les dossiers permettant de trier les emails envoyés, supprimés, brouillons et indésirables n'ont pas été automatiquement reconnu.

De ce fait Outlook à crée ses propres dossiers.

Solution

Pour remédier au problème il faut dans un premier temps faire le ménage dans vos emails pour les déplacer dans ces nouveaux dossiers.

Il ne reste plus qu’a modifier dans Outlook le chemin d’accès au dossier racine.

Aller dans “Fichier” –> “Paramètres du compte” :

Sélectionner le compte OVH puis cliquer sur “Modifier”

Cliquer sur “Paramètres supplémentaires”

Puis modifier le chemin en écrivant “INBOX”

En validant sur “OK” le compte va ce synchroniser correctement sans créer de nouveau dossiers.