Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

Agent SCOM 2012 R2 UR12 (et ultérieur) sur Windows 2003

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) :

clip_image001

clip_image002

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 :

clip_image004[5]

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) :

clip_image006[5]

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é :

clip_image008[5]

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

Azure – Gestion des licences par groupe avec des groupes dynamiques

Description

Pour attribuer une licence a un utilisateur de votre annuaire Azure, cela nécessite l’une des étapes suivantes :

  • Attribution de licences directement aux utilisateurs par l’intermédiaire du portail, de PowerShell ou des API.
  • Attribution de licences à des groupes dans le portail Azure.

Quand vous attribuez des licences à un groupe, tous les membres de ce groupe disposent d’une licence. Si des utilisateurs sont ajoutés au groupe ou en sont supprimés, la licence appropriée leur est attribuée ou retirée.

Vous pouvez utiliser l’attribution de licence basée sur le groupe pour configurer des règles telles que les suivantes :

  • Tous les utilisateurs de votre annuaire obtiennent automatiquement une licence
  • Toute personne avec la fonction appropriée obtient une licence

Configuration

Pour créer un groupe il faut utiliser votre compte d’administration Azure et se rendre à l’adresse suivante : https://portal.azure.com.

Une fois connecté vous devez aller dans le menu « Azure Active Directory ».

clip_image001

Créer un groupe dans le sous menu « Utilisateurs et groupes ».

clip_image002

clip_image003[4]

Puis revenir dans l’onglet « Azure Active Directory » et cette fois ci sélectionner « Licences ».

clip_image004[4]

Une fois que vous êtes dans le menu de vos licences sélectionnez le produit sur lequel vous voulez créer un groupe dynamique et cliquez sur « Attribuer ».

clip_image005[4]

Choisissez le groupe que vous avez crée et configuré le les options de la licence. Cette étape est importante car tous les utilisateur qui seront dans le groupe hériterons de ces options.

clip_image006[4]

clip_image008

Ajouter les membres

clip_image010

L’utilisateur ci-dessous hérite maintenant du groupe «DL_O365_E5»

clip_image011

Information :

Pour plus d’information concernant la configuration, je vous invite à consulter le lien suivant :

Manage Azure Active Directory licencing

SCOM – Requête SQL des agents gérés par une gateway spécifique

La requête SQL ci-dessous affiche les agents gérés par une Gateway spécifique ainsi que le failover configuré ou non.

Use OperationsManager

 

DECLARE @PrimaryServer VARCHAR(50)

SET @PrimaryServer = 'MyGateway'

 

;

 

WITH 

PrimaryRelation (SourceEntityId,agent,PrimaryServer,TargetEntityId)

AS

(

SELECT R.SourceEntityID,SourceBME.DisplayName as Agent,TargetBME.DisplayName as PrimaryServer, R.TargetEntityID

FROM Relationship R WITH (NOLOCK) 

JOIN BaseManagedEntity SourceBME 

ON R.SourceEntityID = SourceBME.BaseManagedEntityID 

JOIN BaseManagedEntity TargetBME 

ON R.TargetEntityID = TargetBME.BaseManagedEntityID 

WHERE R.RelationshipTypeId = dbo.fn_ManagedTypeId_MicrosoftSystemCenterHealthServiceCommunication() 

AND TargetBME.IsDeleted <> '1'  -- AND THE PRIMARY SERVER IS NOT WAITING TO BE DELETED

AND SourceBME.IsDeleted <> '1' -- AND THE AGENT IS NOT WAITING TO BE DELETED

)

,

FailoverRelation (SourceEntityId,agent,FailoverServer,TargetEntityId)

AS

(

SELECT R.SourceEntityID,SourceBME.DisplayName as Agent,TargetBME.DisplayName as FailoverServer, R.TargetEntityID

FROM Relationship R WITH (NOLOCK) 

JOIN BaseManagedEntity SourceBME 

ON R.SourceEntityID = SourceBME.BaseManagedEntityID 

JOIN BaseManagedEntity TargetBME 

ON R.TargetEntityID = TargetBME.BaseManagedEntityID 

WHERE R.RelationshipTypeId = dbo.fn_ManagedTypeId_MicrosoftSystemCenterHealthServiceSecondaryCommunication()

AND TargetBME.IsDeleted <> '1'  -- AND THE FAILOVER SERVER IS NOT WAITING TO BE DELETED

AND SourceBME.IsDeleted <> '1' -- AND THE AGENT IS NOT WAITING TO BE DELETED 

)

 

 

SELECT 

       MTV_HS.[DisplayName] as Agent

       

      ,PrimaryRelation.PrimaryServer

      ,FailoverServer =  -- FIELD RELATED TO 'LEFT OUTER JOIN' ON FailoverRelation TABLE

        CASE

        WHEN FailoverRelation.FailoverServer IS NULL THEN 'NO FAILOVER'

        ELSE FailoverRelation.FailoverServer

        END

      ,[Port]

      ,[InstallTime]

      ,[MaximumQueueSize]

      ,Patch = CASE 

        WHEN [PatchList] like '%UR4%' THEN 'RU4'

        WHEN [PatchList] like '%UR8%' THEN 'RU8'

        WHEN [PatchList] like '%UR11%' THEN 'RU11'

        WHEN [PatchList] = '' THEN '[NO_DATA]'

        END

      ,[IsManuallyInstalled]

      ,[Version]

      ,[ActionAccountIdentity]

      ,[ProxyingEnabled]

      ,[HeartbeatInterval]

      ,[NumberOfMissingHeartBeatsToMarkMachineDown_27AD2E30_EFE0_1A73_8C9D_F0A22B073227] as NumberOfMissingHeartBeatsToMarkMachineDown

      ,MTV_OS.DisplayName as OS

      ,MTV_OS.LogicalProcessors_5CAE4847_F75B_01D0_156E_1658D557B739 as Logic_CPU

      ,MTV_OS.CSDVersion_AFE62B62_74FC_2F06_D8A0_DEE31F14CD33 as ServicePack

      

      

  FROM [OperationsManager].[dbo].[MTV_HealthService] as MTV_HS

  INNER JOIN  [dbo].[MTV_Microsoft$Windows$OperatingSystem] as MTV_OS on MTV_HS.DisplayName = MTV_OS.PrincipalName

 

  INNER JOIN PrimaryRelation on PrimaryRelation.SourceEntityId = MTV_HS.BaseManagedEntityId

  -- THE LEFT OUTER JOIN CAN BE COMMENTED (AND RELATED FIELDS) TO DISPLAY ONLY THE PRIMARY SERVER)

  LEFT OUTER JOIN FailoverRelation on FailoverRelation.SourceEntityId = MTV_HS.BaseManagedEntityId

 

  WHERE IsAgent = '1'

  AND PrimaryServer like '%'+@PrimaryServer+'%'

 

 

  order by MTV_HS.[DisplayName]