> Tech > Mécanisme de découverte

Mécanisme de découverte

Tech - Par iTPro - Publié le 19 août 2010
email

ConfigMgr dispose de plusieurs mécanismes de découverte. Comme on vient de le voir, il est capable d’interroger l’Active Directory pour trouver les stations et serveurs qui s’y trouvent, mais il peut aussi interroger le réseau pour détecter les appareils disposant d’une adresse IP.

 

Le SDK fournit

Mécanisme de découverte

les outils et méthodes pour construire son propre mécanisme de découverte. Plusieurs éditeurs proposent ainsi des mécanismes permettant de découvrir des machines Unix, des routeurs, etc. Nous allons utiliser ce SDK pour « découvrir » dans un premier temps une machine qui n’est pas encore dans l’Active Directory ni sur le réseau (par exemple une station reçue du constructeur et en attente d’affectation dans le stock. Créer un nouvel élément non encore découvert (provisionning) Voir listing 1.

 

La première chose à noter est le CreateObject. Il crée en mémoire une instance de la DLL SMSResGen qui fait partie du SDK. Cela ne peut fonctionner que si la DLL est accessible au script, et que si cette DLL a bien été enregistrée avec « regsvr32 smsrsgenctl.dll ». Le point suivant consiste à appeler une des fonctions exposées par cette DLL, à savoir DDRNew.

 

Le premier argument indique l’architecture de l’objet que l’on souhaite créer, le second le nom de l’agent (astucieusement baptisé invext) et le dernier est le code du site du serveur qui doit le gérer (comme il n’existe pas encore, il ne peut en effet s’appuyer sur les mécanismes d’attribution automatique de site).

 

Le contenu de notre acte de naissance démarre à la ligne suivante DDRAddString consiste à ajouter une propriété de type « chaine de caractères » à notre DDR. Il nous faut spécifier le nom de la propriété, sa valeur, sa longueur max et quelques propriétés. Dans l’architecture System, une clef est le champ Netbiosname: il faut donc indiquer cette propriété.

 

Les indicateurs (flags) indiquent à ConfigMgr comment traiter cette propriété : FLAG_KEY indique que NETBIOSNAME est la clef dans l’architecture existante. FLAG_NAME spécifie que NETBIOSNAME est le nom affiché Le fichier DDR doit être copié dans « C :\Program Files\Microsoft Configuration Manager\inboxes\auth\ddm .box » (Attention, il existe aussi un répertoire « C:\Program Files\Microsoft Configuration Manager\inboxes\ddm.box », ne pas oublier le « auth » )

 

La progression peut être suivie dans DDM.LOG2 . Si l’enregistrement est correct, ConfigMgr effectue les opérations suivantes :

 

⇒ Ajout d’une entrée dans la table Agents – AgentID = (numéro d’ordre) – AgentName = « MonAgent » ⇒ Ajout d’une entrée dans la table DiscItemAgents – DiscArchKey = pointeur sur DiscoveryArchitectures. DiscArchKey (5 pour System) – ItemKey = (numéro d’index) – AgentID = (pointe sur Agents.AgentID) ⇒ Ajout d’un enregistrement dans DiscPropertyDefs (DiscArchKey) pour chacun des champs (un seul ici) – PropertyName = myOtherField – DiscArchKey = pointeur sur l’entrée dans Discovery Architectures (5) – ColumnName = myOtherField0 – ValueType – MaxWidth – Flags

 

Un petit rafraîchissement de la collection All Systems et la future machine apparaît bien dans la liste : Voir Figure 5. Que se passera-t-il lorsque cet élément sera redécouvert par interrogation de l’Active Directory ou du réseau ? Les informations collectées viendront enrichir celles que nous avons indiquées dans notre script, et la mention du nouvel agent viendra s’ajouter dans la liste des agents ayant détecté la ressource.

 

Cela est possible grâce à l’utilisation de la même valeur dans le champ « NETBIOSNAME » qui est une des deux clefs d’une ressource machine (system) dans ConfigMgr (l’autre étant MAC Address). Voir Figure 6.

 

Remarque : dans notre configuration de maquette, la ressource a été redécouverte par ajout du DDR après plusieurs cycles de découverte AD, d’où le fait que INVEXT apparaisse ici en AgentName[4] et non en AgentName[0].

Chaque nouvelle découverte s’ajoute puis décale les plus anciennes vers l’oubli (avant 0). Créer un élément d’un nouveau type Après avoir mené à bien un projet d’architecture et de déploiement d’une solution de télédistribution et de téléinventaire grâce à ConfigMgr, notre Directeur Informatique nous demande comment faire pour gérer la flotte des téléphones portables avec ConfigMgr.

 

Bien sûr, ceux-ci ne disposent pas d’un OS Windows Mobile (sinon ce serait trop facile car ConfigMgr sait gérer les Windows Mobile, et pour cela il fait plus ou moins ce que nous allons faire). Utilisons la même technique que dans le chapitre précédent mais en créant une nouvelle architecture : Voir listing 2.

 

Le fichier DDR doit –de la même façon que précédemmentêtre copié dans « C:\Program Files\Microsoft Configuration Manager\inboxes\auth\ddm.box » (Veiller à ne pas oublier le « auth » ☺) La progression peut être suivie dans DDM.LOG3.

 

Si l’enregistrement est correct, ConfigMgr effectue les opérations suivantes :

 

⇒ Création de la table CUST_ARCH_x_DISC (x = numéro d’ordre) – Champs = myKeyField0, myOtherField0… (des zéros ajoutés au nom) – Ajout d’un enregistrement correspondant aux valeurs ⇒ Création de la vue v_R_CUST_ARCH_x – associée à la table CUST_ARCH_x_DISC – champs = myKeyfield, myOtherfield (sans le zéro) ⇒ Ajout d’une entrée dans la table DiscoveryArchitectures – DiscArchKey = (numéro d’index) – DiscArchName = myArchitecture – BaseTableName = CUST_ARCH_x_DISC ⇒ Ajout d’une entrée dans la table Agents – AgentID = (numéro d’ordre) – AgentName = « MonAgent » ⇒ Ajout d’une entrée dans la table DiscItemAgents – DiscArchKey = pointeur sur DiscoveryArchitectures. DiscArchKey – ItemKey = (numéro d’index) – AgentID = (pointe sur Agents.AgentID) ⇒ Ajout d’un enregistrement dans DiscPropertyDefs (DiscArchKey) pour chacun des champs – PropertyName = myField – DiscArchKey = pointeur sur l’entrée dans Discovery Architectures – ColumnName = myField0 – ValueType – MaxWidth – Flags

 

Comme il ne s’agit pas d’une ressource d’architecture « system », elle n’apparaitra pas dans la collection « All Systems ». En revanche, on peut la voir dans une collection ou dans une requête. Etant donné que notre exemple ne contient pas d’UniqueID, l’affichage dans une collection peut être effectué mais mieux vaut préférer un affichage en requête. On remarquera l’Object Type qui reprend le nom de l’architecture. Voir Figure 7.

 

Le résultat apparaîtra sous cette forme dans les résultats de requête : Voir Figure 8. Cette méthode permet d’ajouter n’importe quel type d’objet dans l’inventaire. Pour mettre à jour les informations, il faudrait par exemple recréer un DDR avec la même valeur dans le même champ « KEY ».

 

Les autres informations seraient alors modifiées (sinon un autre enregistrement serait créé). Quelques subtilités sont apparues dans ConfigMgr concernant la mise à jour des champs multivalués, on les retrouvera dans le SDK. Il est très facile de récupérer un export de la liste des objets puis de modifier le script ci-dessus pour qu’il crée un DDR pour chacun, afin que l’ensemble des objets à gérer apparaisse bien dans ConfigMgr.

Téléchargez gratuitement cette ressource

Sécurité Office 365 : 5 erreurs à ne pas commettre

Sécurité Office 365 : 5 erreurs à ne pas commettre

A l’heure où les données des solutions Microsoft de Digital Workplace sont devenues indispensables au bon fonctionnement de l’entreprise, êtes-vous certain de pouvoir compter sur votre plan de sécurité des données et de sauvegarde des identités Microsoft 365, Exchange et Teams ? Découvrez les 5 erreurs à ne pas commettre et les bonnes pratiques recommandées par les Experts DIB France.

Tech - Par iTPro - Publié le 19 août 2010