Il arrive dans certain cas de figure que nous souhaitions forcer le changement de mot de passe des comptes O365.

S'il s'agit d'un seul utilisateur voici la commande :

Set-MsolUserPassword -UserPrincipalName jdupont@mondomaine.com -ForceChangePasswordOnly $true -ForceChangePassword $true

Prenez soin de modifier le Userprincipalname de la commande sous peine d'obtenir une erreur.

En revanche si l'on veut forcer l'intégralité de la société à changer de mot de passe cela va nécessiter quelques lignes de plus.

# Variables
$LogFolder = "C:\temp"
$LogFile = "$LogFolder\LogO365_Reset.txt"
$LogFileError = "$LogFolder\LogO365_Reset_Error.txt"

# check
If (!(Test-Path $LogFolder)) {
    New-Item $LogFolder -ItemType Directory
    }

# Exceptions
$FilteredUsers = "Userprincipalname1", "Userprincipalname2", "Userprincipalname3" # Ajouter les UPN à ne pas reset (exemple  le compte Admin du Tenant)

# Connect to O365
Connect-MsolService

# Get users
$AllUsers = Get-MsolUser -MaxResults 10000 | select UserPrincipalName

# Force to change Password
$AllUsers | foreach {
    $UPN = $_.UserPrincipalName
    If ($FilteredUsers -eq $UPN) {
        Write-Host "Do not reset Password For $UPN because we had filtered him" | Add-Content $LogFile
        }
    Else {
        Try {
            Set-MsolUserPassword -UserPrincipalName $UPN -ForceChangePasswordOnly $true -ForceChangePassword $true
            Write-Output "Succesfully reset Password For $UPN" | Add-Content $LogFile
            }
        Catch {
            $Date = Get-Date
            Write-Warning "At $Date the following Error Appear $($_)" | Add-Content $LogFileError
            }
        }
    }

Bon courage au service IT pour le nombre d'appel qu'il va recevoir. 

Comme expliqué dans l'article précédent "O365 : Soft Match (SMTP) et Hard Match (ImmutableID)" le Hard Match intervient lorsque le Soft Match n'a pas fonctionné.

Les étapes à suivre sont les suivantes:

1. Récupérer le GUID du compte dans l'Active Direcotry
2. Convertir ce dernier en ImmutableID
3. Appliqué cet ImmutableID au compte Azure Active Directory
4. Relancer une synchronisation via Ad connect 

Voici donc les commandes pour cela.

# Get GUID for User
$User = Get-ADUser jdupont | select ObjectGUID,UserPrincipalName
$Upn = $User.UserPrincipalName
$Guid = $User.ObjectGUID.Guid

# Convert GUID to ImmutableID
$ImmutableId = [System.Convert]::ToBase64String(([GUID]($User.ObjectGUID)).tobytearray())

# Connect MsolService
Connect-Msolservice

# Set ImmutableID to msoluser
Set-MsolUser -UserPrincipalName $Upn -ImmutableId $ImmutableId

Et voila, vous n'avez plus qu'a relancer une Synchor AD Connect via la commande suivante.

Start-ADSyncSyncCycle -PolicyType Delta

Le script SQL ci-dessous propose de lister les détails de l'état et la configuration des antivirus Defender pour des machines gérés par SCCM.

/****** ALL WORKSTATIONS ENDPOINT PROTECTION DETAILS  ******/

	SELECT DISTINCT (S.ResourceID)
	,S.Name0 AS 'Machine Name'
	,AD_Site_Name0 AS 'AD Site'
	,S.Operating_System_Name_and0 AS 'Operating System'
	,CASE [EpProtected]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Protected'
	,CASE [EpAtRisk]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Computer at Risk'
	,CASE [EpNotYetInstalled]
		WHEN 1 THEN 'NOT INSTALLED'
		WHEN 0 THEN 'INSTALLED'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Installed'
	,CASE [EpUnsupported]
		WHEN 1 THEN 'UNSUPPORTED'
		WHEN 0 THEN 'SUPPORTED'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Support'
	,CASE[Inactive]
		WHEN 1 THEN 'INACTIVE'
		WHEN 0 THEN 'ACTIVE'
		ELSE 'UNKNOWN' 
		END AS 'SCCM Client Activity'
	,CASE[NotClient]
		WHEN 1 THEN 'NO'
		WHEN 0 THEN 'YES'
		ELSE 'UNKNOWN' 
		END AS 'SCCM Client'
	,CASE [AmRemediationFailed]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'AntiMalware Failed Remediation'
	,CASE [AmFullscanRequired]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'AntiMalware Full Scan Required'
	,CASE [AmRestartRequired]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'AntiMalware Restart Required'
	,CASE [AmOfflineScanRequired]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'AntiMalware Offline Scan Required'
	,CASE [AmManualStepsRequired]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'AntiMalware Manual Scan Required'
	,CASE [AmRecentlyCleaned]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'AntiMalware Recently Cleaned'
	,CASE [AmThreatActivity]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'AntiMalware Threat Activity'
	,CASE [EpInstallFailed]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Failed Install'
	,CASE [EpEnforcementSucceeded]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Enforce Succeed'
	,CASE [EpEnforcementFailed]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Enforce Failed'
	,CASE [EpPendingReboot]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Pending Reboot'
	,CASE [Unhealthy]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Unhealthy'
	,CASE [SignatureUpTo1DayOld]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Signature Age 1 day old'
	,CASE [SignatureUpTo3DaysOld]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Signature Age 3 day old'
	,CASE [SignatureUpTo7DaysOld]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Signature Age 7 day old'
	,CASE [SignatureOlderThan7Days]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Signature Age over 7 day old'
	,CASE [NoSignature]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'No Signature'
	,CASE [AmPending]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'AntiMalware Pending'
	,CASE [LastScanUpTo2DaysOld]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Last Scan 2 days old'
	,CASE [LastScanUpTo8DaysOld]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Last Scan 8 days old'
	,CASE [LastScanUpTo31DaysOld]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Last Scan 31 days old'
	,CASE [LastScanOver31DaysOld]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Last Scan Over 31 days old'
	,CASE [Healthy]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Healthy'
	,CASE [Active]
		WHEN 1 THEN 'ACTIVE'
		WHEN 0 THEN 'INACTIVE'
		ELSE 'UNKNOWN' 
		END AS 'Client Activity'
	,CASE [EpUnmanaged]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Not Managed'
	,CASE [EpToBeInstalled]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint To be installed'
	,CASE [EpManaged]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Managed'
	,CASE [EpInstalled]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Managed'
	,CASE [EpEnforced]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Enforced'
	,CASE [EpEnabled]
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Endpoint Enabled'
	
	,CASE AMSH.Enabled 
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'AntiMalware_Enabled'
	,AMSH.Version as AntiMalware_Version
	--,AMSH.ProductStatus
	,CASE AMSH.RtpEnabled
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'RealTime_Ptct_Enabled'
	,CASE AMSH.OnAccessProtectionEnabled -- Specifies whether the computer is monitoring file and program activity on your computer
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'OnAccess_Ptct_Enabled'
	,CASE AMSH.IoavProtectionEnabled -- Scan all downloaded files and attachments
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Downloaded_Ptct_Enabled'
	,CASE AMSH.BehaviorMonitorEnabled
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Behavior_Monitor_Enabled'
	,CASE AMSH.AntivirusEnabled
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Antivirus_Enabled'
	,CASE AMSH.AntispywareEnabled
		WHEN 1 THEN 'YES'
		WHEN 0 THEN 'NO'
		ELSE 'UNKNOWN' 
		END AS 'Antispyware_Enabled'
	,AMSH.EngineVersion
	,AMSH.LastQuickScanDateTimeStart as 'Last QuickScan DateTime Start'
	,AMSH.LastQuickScanDateTimeEnd as 'Last QuickScan DateTime End'
	,AMSH.LastFullScanDateTimeStart as 'Last FullScan DateTime Start'
	,AMSH.LastFullScanDateTimeEnd as 'Last FullScan DateTime End'
	,AMSH.LastFullScanAge as 'Last FullScan Age'
	,AMSH.LastQuickScanAge as 'Last Quick Scan Age'
	,AMSH.AntivirusSignatureUpdateDateTime as 'Antivirus Signature Update DateTime'
	,AMSH.AntiSpywareSignatureUpdateDateTime as 'AntiSpyware Signature Update DateTime'
	,AMSH.AntivirusSignatureAge as 'Antivirus Signature Age'
	,AMSH.AntispywareSignatureAge as 'Antispyware Signature Age'
	,AMSH.AntivirusSignatureVersion as 'Antivirus Signature Version'
	,AMSH.AntispywareSignatureVersion as 'Anti spyware Signature Version'
	
	FROM [CM_BIM].[dbo].[v_EndpointProtectionStatus] EPPS /*(v_EndpointProtectionStatus: Fournit un résumé de l'état des clients Endpoint Protection global pour chaque ordinateur)*/
	INNER JOIN v_R_System S on S.ResourceID = EPPS.ResourceID
	INNER JOIN v_GS_AntimalwareHealthStatus AMSH on AMSH.ResourceID = EPPS.ResourceID /*(v_GS_AntimalwareHealthStatus:  Most recent snapshot of the AntimalwareHealthStatus WMI class for each client where EndPoint Protection is installed)*/
	

Dans les environnements modernes, il est de plus en plus fréquent de rencontrer des serveurs déployés en mode “Server Core” (sans interface graphique) et bien sûr sans accès à Internet.

Le rôle RDS License Server est supporté sur ce type de serveur, mais son installation n’est pas aussi bien documentée qu’en mode graphique…

Il serait bien sûr possible de passer par une console installée sur un serveur de rebond, mais ca serait bien moins amusant! Et les informations suivantes peuvent également servir dans le cadre d’un déploiement automatisé par Ansible ou Powershell DSC.

Activation du serveur

Il est dans un premier temps nécessaire d’activer la fonctionnalité License Server. Le serveur n’ayant pas accès à Internet, il n’est pas possible de procéder à une activation automatique.

Il est cependant possible d’obtenir la clé d’activation à partir d’un autre poste disposant d’un accès à Internet :

1. Récupérez le ProductId du License Server à l’aide de la commande suivante :
   (Get-WmiObject Win32_TSLicenseServer -Property ProductId).ProductId
   

2. Rendez-vous sur https://activate.microsoft.com/ et sélectionnez l’option Activate a License Server
   

3. Indiquez le ProductId obtenu précédemment ainsi que le reste des informations demandées :
   

4. Après validation de vos informations, le site renvoie le License Server Id nécessaire à la poursuite de l’activation :
   

5. L’activation peut désormais être finalisée à l’aide des commandes suivantes (pensez à remplacer le License Server Id par la valeur obtenue précédemment, en supprimant les tirets)
   $serverId = 'VTXXXXXXXXXXXXXXXXX'
   $wmiClass = ([wmiclass]"\\localhost\root\cimv2:Win32_TSLicenseServer")
   $wmiClass.ActivateServer($serverId)

6. En cas de réussite de l’opération, la valeur retournée pour ActivationStatus doit être 0 :
   

Ajout des CAL

Une fois la fonctionnalité License Server activée, il est nécessaire de provisionner les licences d’accès (CAL) à proprement parler, afin qu’elles puissent être attribuées aux utilisateurs qui se connectent au bureau à distance.

1. Récupérez le License Server Id depuis l’étape précédente ou à l’aide des commandes suivantes :
   $wmiClass = ([wmiclass]"\\localhost\root\cimv2:Win32_TSLicenseServer")
   $wmiClass.GetLicenseServerId().sLicenseServerId
   

2. Rendez-vous sur https://activate.microsoft.com/ et sélectionnez l’option Install client access licenses
   

3. Indiquez le License Server Id, sélectionnez le type de licence correspondant à la commande et complétez le reste des informations :
   

4. Indiquez le nombre de licences correspondant à la commande, ainsi que l’agreement number du contrat :
   

5. Confirmez. Le service d’activation renvoie la clé d’activation des CAL
   

7. L’activation des CAL peut désormais être finalisée à l’aide des commandes suivantes (pensez à remplacer le License Pack Id par la valeur obtenue précédemment, en supprimant les tirets)

$licensePackId = 'Y3XXXXXXXXXXXXXXXX'

$wmiClass = ([wmiclass]"\\localhost\root\cimv2:Win32_TSLicenseKeyPack")

$wmiClass.InstallLicenseKeyPack($licensePackId) 

8. En cas de réussite de l’opération, Return Value doit afficher 0 et KeyPackId contient l’Id du pack de licence ajouté (incrémenté de 1 à chaque ajout d’un nouveau pack sur le serveur).
   

Et voilà, votre serveur RDS License Server est prêt!

Le rôle NPS (Network Policy Server) reste le seul moyen natif d’utiliser un serveur Windows pour réaliser des authentifications RADIUS, ce qui est très utile notamment pour gérer l’authentification à des appliances réseau, des bornes Wifi ou même des utilisations plus avancées comme de l’authentification par certificat avec AlwaysOn VPN.

Bien qu’il n’ait pas évolué depuis plusieurs versions de Windows et que sa partie NAP (Network Access Protection) soit dépréciée depuis Windows 2012 R2, il reste parfaitement fonctionnel pour son rôle de serveur RADIUS.

J’ai donc récemment déployé un serveur NPS sous Windows 2019 sur un serveur flambant neuf, configuré mon client Radius (une appliance NTP) ainsi qu’une stratégie d’authentification basique pour pouvoir utiliser des identifiants de l’AD pour me connecter à l’appliance.

Malheureusement, le premier essai de connexion fut un échec. Pas d’inquiétude, les stratégies NPS sont souvent assez obscures et il est vite arrivé de manquer un paramètre… mais là tout à l’air bon..

J’active donc les logs d’audit de connexion, ils permettent souvent d’en apprendre plus sur les raisons de l’échec. Sauf que cette fois, ils sont intégralement vides : non seulement il n’y a pas d’erreur, mais il n’y a en réalité pas le moindre évènemen, comme si la requête RADIUS n’arrivait jamais au serveur.

Les règles de firewall Windows créée automatiquement lors de l’installation du rôle NPS (groupe Network Policy Server) sont pourtant bien présentes et actives, et l’administrateur réseau me confirme que les paquets arrivent bien jusqu’au serveur.

Il est donc temps de sortir Wireshark : effectivement, les paquets RADIUS arrivent bien au serveur mais ensuite rien, aucune réaction; encore une fois comme si la requête n’arrivant jamais au rôle NPS…

Après bien des tentatives infructueuses, j’essaye en désespoir de cause de désactiver le firewall Windows… et miracle, tout tombe en marche.

Le problème se situe donc au niveau du firewall… Après quelques recherches, il apparaît que les règles natives sont configurées pour ne fonctionner que pour le service IAS, ce qui est normal. Par contre, dans Windows 2019, ce service utilise un identifiant de sécurité (service SID) qui l’empêche d’être la cible d’une règle de firewall… et donc la règle ne fonctionne pas.

Deux solutions s’offrent donc à nous :

• Reconfigurer le service pour retirer cette restriction à l’aide de la commande sc.exe sidtype IAS unrestricted
• Reconfigurer les règles de firewall pour qu’elles fonctionnent avec n’importe quel service : Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any

Après avoir exécuté une de ces deux solutions, tout rentre dans l’ordre !

Pour rappel, Defender Security Center représente la brique et le portail dédié associé a Defender for Endpoint, et représente l’offre SAS de Microsoft dans le domaine des EDR (Endpoint Detection and Response), encore appelé antivirus de nouvelle génération.

Dans le cadre de l’exploitation des données remontées par la solution, il peut être utile de collecter des données de diagnostique sans avoir a se connecter sur la machine cible.

Dans le portail Security Center, dans la zone Device Inventory, cliquer sur le device cible pour ouvrir la page du device.

Cliquer sur et sélectionner Collect investigation package. La demande est initiée.

Apres quelques minutes, dans le même menu, sélectionner Action Center pour afficher la disponibilité du package

Cliquer sur le lien Package collection package available pour télécharger le package.

Le package contiens différents éléments:

- Programmes installés

- Diagnostiques réseaux ()

- Une liste un dump du contenu du dossier Windows\Prefetch (cf: Prefetcher — Wikipédia (wikipedia.org))

- Le détail des processes en cours

- les taches planifiées

- un export de l’eventlog Security

- Le détails des services

- les session SMB

- les infos du systeme (systeminfo.exe)

- les listes de contenu de differents dossier Temporaires

- Les users et groupes locaux

- La collecte de diagnostiques générée avec l’outil mpcmdrun.exe  (cf: Utiliser la ligne de commande pour gérer l’Antivirus Microsoft Defender - Windows security | Microsoft Docs ;  Collecter des données de diagnostic de l’Antivirus Microsoft Defender - Windows security | Microsoft Docs)

Lorsque l'on utilise Active Direcotry et Azure Active Directory, il se peut que l'on soit confronter à des conflits car l'utilisateur existe déjà dans les deux environnements (selon divers scénarios).

Quand il s'agit bien du même utilisateur (et non pas un homonyme) il est important  de créer un "matching" entre les deux comptes pour que l'AD Connect puisse les voir comme un seul et même compte et les synchroniser.

Pour ce faire il existe deux méthodes:

1. Le Soft Match appelé aussi SMTP Matching
2. Et le Hard Match (basé sur l'ImmutableID)

Le Soft Match

Le soft match appelé aussi "smpt matching" consiste à s'appuyer sur l'adresse SMTP de l'utilisateur pour faire l'association entre les deux comptes.

Ce dernier est censé fonctionner dans la plupart des cas, mais pour cela il y a quelques conditions à respecter. 

1. L'utilisateur doit posseder une adresse email sur Microsoft Exchange Online.
   1. s'il s'agit d'un contact ou d'un groupe à extension de messagerie le soft match sera basé sur l'attribt "proxyaddresses"
2. Vous ne devrez pas modifier l'adresse SMTP principale de l'utilisateur durant l'opération.
3. Les adresses SMTP sont considérées comme unique assurez vous que seul cet utilisateur possède cette adresse.

Le Hard Match

Le hard match entre en action lorsque le soft match n'a pas réussi, ce dernier consiste à récupérer le GUID du compte Active Directory pour le transformer en ImmutableID et enfin l'appliquer au compte Azure Active Directory.

Cette opération permettera de faire la liaison entre les deux comptes pour n'en faire qu'un synchronisé.

Dans Power BI, l’info du dernier rafraichissement d’un dashboard ne fait pas l’objet d’une fonctionnalité directe identifiée comme telle.

Il s’agit d’une info bien sur importante. Pour l’implémenter, la procédure n’est pas très compliquée.

Dans l’editeur de requete, creer une nouvelle requete vide.

Renommer la requête avec un nom explicite.

Cliquer sur Advanced Editor pour éditer la nouvelle requête.

Ecrire la requete comme ci-dessus (Source = #table(type table[Date Last Refreshed=datetime], {{DateTime.LocalNow()}})

La valeur de la date et heure actuelle s’affiche.

Valider en cliquant Close & Apply

Sur la page du dashboard dans la liste des champs (Fields) Faite un clic droit et selectionner New measure

Dans la barre éditeur de la mesure, tapez le texte ci-dessus (Last Refreshed = VALUES(‘Date Last Refreshed’[Date Last Refreshed])

la mesure est crée et va pouvoir etre utilisé dans une visualization.

Selectionner une Visualization de type Card

Associer a cette visualization la mesure crée.

Voila. Vous pouvez bien sur changer l’apparence de la visualization (par ex la couleur de fond) dans ses propriétés.

Débutons par un bref rappel sémantique : dans SCOM, le terme workflow désigne l’ensemble des éléments qui constituent un moniteur, une règle, une découverte ou une tache. Un workflow peut donc être constitué d’une data source, d’une ou plusieurs probes, de condition detections, de writeactions…

La grande majorité des Management Packs contient des workflows consistant en un assemblage de modules préexistants, par exemple :

• Une datasource basée sur le module “scheduler” pour déclencher le workflow à intervalle régulier
• Une probe basée sur le module “powershell script” pour exécuter un script. C’est ce dernier qui ira effectuer des tests et en renverra le résultat dans le workflow
• Une ou plusieurs condion detections basées sur le module “Filter”, afin de détecter si le résultat du script indique un problème ou non
• Une writeaction pour déclencher l’alerte si le filtre indique un problème.

Ces modules préexistants sont la vraie fondation de tout workflow SCOM, et leur code est en général du C# contenu dans une dll : c’est ce que l’on appelle des Modules Natifs (“native modules”).

Certains Management Packs poussent ce principe encore plus loin, en intégrant des modules créés de toutes pièces et dédiés à leur utilisation au lieu d’intégrer les modules natifs dans leurs workflows : on les appelle des modules managés (managed modules).

Les raisons de ce choix sont le plus souvent :

• L’ajout de fonctionnalités irréalisables autrement
• La réutilisation de code compilé préexistant
• L’optimisation des performances des workflows : en effet, un workflow powershell tel que décrit ci-dessus permet de découvrir l’immense majorité des cas rencontrés. Cependant, il nécessite une exécution du script complète à chaque fois : chargement de powershell, chargement des modules powershell, authentification sur l’application à interroger, collecte des données puis déconnexion, déchargement de powershell etc. Un managed module reste lui en mémoire indéfiniment et peut ainsi ne boucler que sur la partie “collecte des données”, ce qui allège grandement le traitement.

Malheureusement cette technique impacte aussi fortement la lisibilité du code et la possibilité de le débugger par n’importe qui, puisque tout ou partie du workflow est maintenant “caché” dans une dll.

Prenons un exemple concret : les dernières versions du Management Pack pour SQL Server intègrent des managed modules, et il arrive parfois que l’alerte suivante se déclenche : MSSQL on Windows: Database is in offline/recovery pending/suspect/emergency state.

Pourtant, le détail de l’alerte n’est pas toujours probant puisqu’il peut n’indiquer que les informations suivantes :

• MonitoringStatus : Bad
• DatabaseState : ONLINE
• IsAccessible : false
• IsMirroringMirror : false
• IsAlwaysOnReplica : true
• ErrorCode : 0
• ErrorDescription : <vide>

Très insuffisant pour comprendre d’où vient le problème… Dans ce genre de cas, il est donc nécessaire d’aller voir comment fonctionne le moniteur d’où provient l’alerte pour tenter de comprendre son passage en échec. En remontant le fil du workflow, on constate que les tests à proprement parler sont réalisés dans une Probe nommée MSSQL on Windows: Database Status Probe Action, dont il n’est pas possible de voir le fonctionnement directement dans le code du Management Pack puisqu’elle repose sur un Managed Module :

Nous avons cependant deux informations utiles :

• Assembly : c’est le nom de la dll qui contient le code compilé du module
• Type : c’est le nom de la fonction qui produit les données utilisées par le moniteur.

La dll peut être récupérée sur n’importe quel serveur SQL disposant d’un agent SCOM dans le dossier Health Service State, ou en l’extrayant du fichier .mpb du management pack avec l’outil MPBUtil de Silect.

Elle peut ensuite être ouverte à l’aide de l’outil gratuit JetBrains dotPeek.

Une fois ouverte, on retrouve la fonction DBStatusMonitoring en suivant l’arborescence :

Un clic-droit > go to implementation permet de retrouver le code exécuté par cette fonction à proprement parler et, en particulier, une zone que l’on interprète facilement comme étant l’exécution d’une requête SQL résultant en plusieurs champs qui correspondent complètement aux détails de notre alerte d’origine :

Cependant, la requête SQL a proprement parler n’est pas visible ici. Elle est en réalité contenue dans une “Ressource”  (un champ texte annexe de la dll) nommée GetDBStatuses :

Retournons donc dans l’explorateur de la dll pour ouvrir les ressources, dans laquelle nous allons rechercher GetDBStatuses. Et voilà notre requête SQL :

Vous pouvez désormais copier cette requête et l’analyser et l’exécuter manuellement pour comprendre d’où provient l’alerte!

D’autres modules managés auront un fonctionnement différent, mais le principe d’analyse restera identique… A vous de jouer!

Description du problème
Après avoir remplacé un certificat wildcard par un certificat SAN, les clients distants utilisant Microsoft Outlook ne peuvent plus se connecter à leurs comptes de messagerie sur un serveur Exchange à l'aide de la méthode de proxy HTTP. Outlook affiche le message d'erreur dessous, puis demande à plusieurs reprises un mot de passe:

Explication et Résolution

Microsoft Outlook 2016 utilise exclusivement la découverte automatique pour configurer les comptes Exchange. Il faut donc s’assurer que l’autodiscover utilise le nom principal correct du certificat :

• Se connecter au serveur Exchange et démarrer Exchange Management Shell puis exécuter la commande Get-OutlookProvider -Identity EXPR | fl
• Vérifier les valeurs:
  CertPrincipalName - doit avoir le nom principal commun et correct du certificat SSL au format: msstd:mail.domain.com
  Server - doit être vide

--> si la valeur du paramètre CertPrincipalName est incorrecte, la commande suivante sera exécutée pour la modifier:
Set-OutlookProvider EXPR -CertPrincipalName msstd: mail.domain.com
 Vérifier le résultat via l’exécution de la commande : Get-OutlookProvider -Identity EXPR | fl CertPrincipalName

--> si la valeur du champ le serveur n'est pas vide, exécuter la commande suivante pour l'effacer: Set-OutlookProvider -id EXPR  $null

Vérifier le résultat via l’exécution de la commande : Get-OutlookProvider -Identity EXPR | fl server