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
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.
Pourquoi la 5G est-elle faite pour votre entreprise ? La 5G peut améliorer la vitesse, la fiabilité et la capacité de votre réseau, permettant ainsi une meilleure collaboration, une productivité accrue et une prise de décision plus rapide. Notre livre blanc " The Big Book of Enterprise 5G" vous fournit les informations stratégiques dont vous avez besoin pour prendre des décisions éclairées et préparer votre entreprise à prospérer dans l'ère de la 5G. Cradlepoint, part of Ericsson est le leader mondial des solutions de réseau sans fil 4G LTE et 5G fournies via le cloud. Connectez vos employés, lieux et objets avec la 4G LTE et la 5G pour un WAN sans fil d'entreprise.
