Configuration de Gestion des actifs › Signatures logicielles personnalisées › Création de scripts personnalisés de signatures intelligentes

Création de scripts personnalisés de signatures intelligentes

En tant que développeur, vous pouvez créer des scripts de signatures intelligentes personnalisés pour tout logiciel que vous utilisez pour lequel CA ne fournit pas de script de ce type.

Planification de script de signatures intelligentes

Remarques concernant la conception de scripts de signatures intelligentes

• Les scripts de signatures intelligentes permettent de détecter les versions finales actuelles et futures de produits. En tant qu'auteur, veillez à examiner le système de manière à créer des scripts qui, une fois écrits, pourront perdurer sur le long terme.
• Il est recommandé de limiter le nombre de définitions de scripts de signatures intelligentes, chacune couvrant plusieurs produits. Une bonne pratique est de créer un script de signatures intelligentes pour chaque fournisseur et un script de signatures intelligentes par fournisseur et par catégorie de logiciel pour les grands fournisseurs. Par exemple : IBM – Logiciels de base de données, Microsoft - Logiciels de base de données, Microsoft – Logiciels bureautiques, Apache – Logiciels bureautiques et CA – Logiciels de gestion. Pour plus de facilité d'utilisation, veillez à garder les noms de catégorie synchronisés pour tous les scripts de signatures intelligentes.
• Un script de signatures intelligentes contient un script principal et peut comporter plusieurs fichiers de données, qui eux-mêmes peuvent être des scripts. Vous pouvez assurer une conception claire et opérationnelle au niveau fournisseur ou catégorie en utilisant les fichiers de données en tant que détenteurs de scripts pour la détection de produit. Le script principal, qui est spécifique au fournisseur, appelle tous les autres scripts (données). Ces scripts, à leur tour, détectent des produits distincts. Pour étendre la fonctionnalité d'un script de signatures intelligentes, créez une version de ce dernier spécifique au fournisseur, en ajoutant des scripts existants nouveaux ou mis à jour plutôt qu'en ajoutant un nouveau script complet de signatures intelligentes. Les versions sont des chaînes intégrées dans un script unique de signatures intelligentes et ne viennent donc pas encombrer l'interface utilisateur. Limitez autant que possible la liste des scripts de signatures intelligentes de niveau supérieur.
• Les logiciels qui sont détectés par le biais d'analyses heuristiques ou de signatures traditionnelles utilisent une relation univoque entre les produits logiciels et les versions finales. Grâce aux scripts de signatures intelligentes, vous pouvez contrôler ce comportement étant donné que vous créez à la fois les produits détectés et les versions finales. Il est recommandé de créer une relation un-à-plusieurs entre les produits détectés et les versions finales pour les trois raisons suivantes :
  1. Un produit peut avoir plusieurs versions finales.
  2. La quantité de données requises en cas d'utilisation d'une relation univoque est nettement supérieure à celle d'une relation un-à-plusieurs.
  3. Et surtout, CA DSM alimente CA Software Compliance Manager (SCM) avec les informations de détection. SCM fonctionne selon les produits DSM, et non selon les versions finales. Prenez donc compte de cet aspect et créez des produits détectés basés sur leur mode de licence. De cette façon, vous augmentez la probabilité que chaque produit auquel SCM peut attribuer une licence corresponde à un produit unique détecté par DSM. Par ailleurs, vous pouvez réaliser une détection granulaire au niveau des versions finales (et des patchs) et une détection explicite au niveau des produits.
• Les produits, versions finales et patchs créés par les scripts de signatures intelligentes (définitions des logiciels détectés) sont identifiés par un nom et une étiquette de version, ainsi que par leur emplacement dans la hiérarchie de détection d'un script de signatures intelligentes. Une étiquette de version vide est permise et considérée comme une version distincte (la version vide). Les définitions de logiciels détectée par les scripts de signatures intelligentes sont distinctes des définitions de logiciels heuristiques, personnalisées et fournies par CA, même si elles ont le même nom et la même version. En plus, différents scripts de signatures intelligentes peuvent créer des définitions différentes avec des noms et des versions identiques.
• Utilisez les fonctions DMscript et fournissez des noms de logiciels et des versions à chacune d'elles.
• Lors de la création d'une définition détectée, un fabricant peut être spécifié. Cette information peut provenir de l'UUID ou du nom. L'UUID du fabricant doit correspondre à celui d'un fabricant existant. S'il n'existe pas, le fabricant n'est pas spécifié dans la définition détectée. Le nom du fabricant peut correspondre à celui d'un fabricant existant ou nouveau. Dans ce dernier cas, le fabricant est créé et la définition détectée lui est affectée. Un fabricant existant peut être fourni par CA, créé par un script personnalisé ou encore créé par la détection de logiciel heuristique.
• Une définition détectée peut également être affectée à une catégorie. Cette information peut provenir de l'UUID ou du nom. Si elle est issue de l'UUID, la catégorie doit exister. Si elle est issue du nom, la catégorie est créée si elle n'existe pas encore. Une catégorie existante peut être une catégorie fournie par CA ou personnalisée.

Une bonne pratique pour le comportement des scripts de signatures intelligentes est renseignée ci-dessous, pour trois produits différents : Microsoft Windows, Microsoft Office et Microsoft SQL Server.

Retour au début

Attribution d'un nom à un produit

Vérifiez que le produit reflète l'entité commercialisable sous licence. La meilleure pratique pour attribuer un nom est la suivante (les crochets représentent les éléments facultatifs) :

• Nom : "<Manufacturer> <Product> [<Edition>] [<Architecture>] [<Language>]" – Le cas échéant, ajoutez l'édition. Si les licences dépendent de l'architecture ou de la langue, incluez-la dans le nom. Veillez à inclure ces informations uniquement si nécessaire, afin de réduire le nombre de produits créés.
• Etiquette de version : "<major>[.<minor>]" – Distingue une version des autres versions.

Exemple :

• Nom : "Microsoft Windows 7 Edition Intégrale"

  Etiquette de version : "6.1"
  Utilisez à la fois les versions majeure et mineure afin de distinguer la version de Windows Vista (6.0) et de Windows 8 (6.2). Supprimez le 7 du nom si nécessaire.

• Nom : "Microsoft Office Professionnel Plus 2010"

  Etiquette de version : "14"
  Utilisez uniquement la version majeure car elle permet de distinguer deux versions finales d'Office. Supprimez le 2010 du nom si nécessaire.

• Nom : "Microsoft SQL Server 2008 R2 Enterprise"

  Etiquette de version : "10.5"
  Utilisez à la fois les versions majeures et mineures pour distinguer la version d'autres versions. Supprimez le 2008 R2 du nom si nécessaire.

Fournissez les propriétés facultatives suivantes si disponibles, afin de les insérer dans des colonnes dédiées dans la base de données : VersionNumber, Language, Bitness, Architecture, Manufacturer, Category et Description.

Retour au début

Attribution d'un nom de version finale

Vérifiez que la version finale capture autant d'informations que possible concernant le logiciel détecté et qu'elle est liée à un produit. La meilleure pratique pour attribuer un nom est la suivante (les crochets représentent les éléments facultatifs) :

• Nom : "<Manufacturer> <Product>[ <Edition>] [<Architecture>] [<Language>]"
• Etiquette de version : "<major>.<minor>.<minor’>.<minor’’> [<release/service pack>]" – Incluez autant de détails que possible. Chaque architecture et langue a un enregistrement de version finale distinct, mais toutes sont liées au même produit.

Exemple :

• Nom : "Microsoft Windows 7 Edition Intégrale x64 fr-fr"

  Etiquette de version : "6.1.7601 Service Pack 1 Build 7601"

• Nom : "Microsoft Office Professionnel Plus 2010 x64 fr-fr"

  Etiquette de version : "14.0.6112.5000 Service Pack 1"

• Nom : "Microsoft SQL Server 2008 R2 Enterprise 64 bits fr-fr"

  Etiquette de version : "10.50.1617.0 Service Pack 1"

Fournissez les propriétés facultatives suivantes si disponibles, afin de les insérer dans des colonnes dédiées dans la base de données : VersionNumber, Language, Bitness, Architecture, Manufacturer, Category et Description.

Retour au début

Attribution d'un nom à une instance de version finale

L'instance de version finale est l'enregistrement de détection réel qui lie une version finale à un ordinateur et fait partie de l'inventaire des logiciels. Un ordinateur peut être équipé de plusieurs instances de la même version finale. Une installation peut avoir des propriétés supplémentaires qui sont spécifiques à l'instance.

Exemple :

• Instance Microsoft Windows 7 Edition Intégrale :

  InstallPath : C:\Windows

  Origin=Forward Inc

  TrustLevel=5

• Instance Microsoft Office Professionnel Plus 2010 :

  InstallPath : C:\Program Files\Office

  ProductGUID : FBD367D1-642F-47CF-B79B-9BE48FB34007

  CustomData : Product-ID=02257-210-8656854-49625

  Origin=Forward Inc

  TrustLevel=5

• Instance 1 de Microsoft SQL Server 2008 R2 Enterprise :

  InstallPath : C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER

  Label : MSSQLSERVER

  CustomData : CPU=2/8/16 ; RAM=32 Go ;

  Origin=Forward Inc

  TrustLevel=5

• Instance 2 de Microsoft SQL Server 2008 R2 Enterprise :

  InstallPath : C:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS

  Label : EXPRESS

  CustomData : CPU=2/8/16 ; RAM=32 Go ;

  Origin=Forward Inc

  TrustLevel=5

Fournissez les propriétés facultatives suivantes si disponibles, afin qu'elles soient insérées dans des colonnes dédiées dans la base de données : Label, InstallPath, SerialNumber, ProductGUID, LastAccessed, Origin, TrustLevel et CustomData.

La propriété CustomData est utilisée pour collecter des informations spécifiques à une instance qui affectent les licences. Sa taille est limitée à 255 caractères. Cette propriété peut contenir des informations concernant le nombre de processeurs, noyaux ou threads, et la mémoire. CA ITCM n'utilise pas les données personnalisées collectées, mais elles peuvent servir dans des solutions élaborées pour certains secteurs.

Retour au début

Attribution d'un nom à un patch

Vérifiez que le patch capture autant d'informations que possible concernant le logiciel détecté et qu'il est lié à une version finale. Les patchs qui sont détectés à l'aide des scripts de signatures intelligentes ne sont pas utilisés par le gestionnaire de patchs DSM.

Exemple :

Nom : "KB971033 x64 fr-fr"
Etiquette de la version : ""

Fournissez les propriétés facultatives suivantes si disponibles, afin qu'elles soient insérées dans des colonnes dédiées dans la base de données :

• VersionNumber Language
• Bitness
• Architecture
• Manufacturer
• Category et
• Description

Retour au début

Attribution d'un nom à une instance de patch

L'instance de patch est l'enregistrement de détection réel qui lie un patch à un ordinateur et fait partie de l'inventaire des logiciels. Un ordinateur peut être équipé de plusieurs instances de la même version finale. Chacune de ces instances de version finale peut être équipée ou non du patch. Par conséquent, créez une instance de patch pour chaque instance de version finale. Un patch peut avoir des propriétés supplémentaires qui sont spécifiques à l'instance.

Fournissez les propriétés facultatives suivantes si disponibles, afin qu'elles soient insérées dans des colonnes dédiées dans la base de données : Label, InstallPath, SerialNumber, ProductGUID, LastAccessed, Origin, TrustLevel et CustomData.

Exemple :

Instance KB971033 x64 fr-fr :

Origin=Forward Inc
TrustLevel=5

Retour au début