Migration Vers GLPI pour la Gestion de Tickets en Entreprise

Problématique :

Actuellement, nous utilisons un système de gestion de tickets interne pour répondre aux demandes de tous nos clients. Malheureusement, ce logiciel commence à être vraiment dépassé et lent, ce qui pose problème car la gestion des tickets est l’une des principales tâches de notre entreprise. Nous devons donc mettre en place une meilleure alternative. Mon responsable a demandé que le GLPI soit configuré pour fonctionner exactement comme notre ancien système de tickets, sa seule exigence étant que le GLPI tienne nos clients informés par des courriels détaillant le statut des tickets.

Dans notre entreprise, nous traitons divers clients et diverses infrastructures, alors pourquoi ne peuvent-ils pas se rendre sur le GLPI en libre-service et créer eux-mêmes les tickets ?

Comme l’a dit mon chef, c’est juste une question d’habitude pour eux, habituellement lorsqu’ils rencontrent un problème, ils nous envoient un courriel et ce courriel est converti en TICKET par mon collègue de la hotline, qui est disponible pour prendre les appels et transformer ces demandes ou problèmes en tickets pour moi et mes collègues.

J’ai été chargé de mettre en production le GLPI pour l’entreprise ; une installation de base de GLPI 9 existait déjà sur une VM à des fins de test, mais c’était un projet qui n’avait jamais vraiment progressé jusqu’à ce qu’il me soit attribué. Il y avait également une VM GLPI 10 créée pour tester le nouveau GLPI V10 lors de sa sortie.

Lorsque j’ai commencé à travailler sur GLPI, l’installation de base était déjà faite grâce à mes collègues, donc l’une des premières étapes a été d’effectuer la liaison LDAP pour pouvoir utiliser notre serveur AD pour se connecter à GLPI.

Il est également important de noter que le GLPI était destiné à être utilisé uniquement en interne, donc aucun accès depuis l’extérieur à l’exception d’un accès **OpenVPN **pour le télétravail.

Liaison LDAP :

La première chose que j’ai faite a été de lier notre serveur Active Directory à GLPI, pour des mesures de sécurité, les informations ont été censurées :

Après que la liaison a été complétée, nous avons pu synchroniser tous nos utilisateurs. Maintenant que les utilisateurs étaient synchronisés, je devais m’assurer que la gestion des tickets fonctionnait correctement, alors j’ai d’abord géré les profils d’utilisateurs. Vu la nature de notre petite entreprise, nous avons besoin de nombreux droits pour la gestion des tickets, car c’est seulement nous qui gérons le GLPI, j’ai donc augmenté leurs droits afin qu’ils puissent manipuler librement les tickets.

Il faut maintenant importer nos clients, vu que les clients n’auront jamais accès à notre GLPI en libre-service, nous avons simplement besoin de ces utilisateurs et entités pour activer le suivi par courriel et l’affectation des tickets.

J’ai exporté un CSV de notre ancien système de tickets et j’ai pu l’injecter dans le nouveau serveur GLPI à l’aide d’un plugin, ce qui m’a permis de créer une entité pour chaque client et, au sein de cette entité, de créer un utilisateur portant le même nom que l’utilisateur, car pour ajouter un demandeur dans GLPI, nous avons besoin d’un utilisateur réel. Ainsi, pour des raisons de sécurité, j’ai créé un profil appelé ‘Client’ qui avait strictement interdiction d’accéder à toute ressource dans notre GLPI, car les comptes clients ne doivent pas être utilisés pour se connecter.

Après cela, j’ai créé un modèle simple qui nous permettait de masquer certaines options que nous n’utilisons pas dans notre flux de travail de notre Hotline.

NOTIFICATIONS EMAIL:

Les seules notifications réellement nécessaires pour ce flux de travail sont spécifiquement demandées pour : l’ouverture d’un nouveau ticket et la clôture du ticket. Donc tout d’abord, j’ai dû configurer l’email depuis lequel ces notifications seront envoyées.

Après avoir entré les détails du serveur de messagerie, j’ai pu effectuer quelques tests et, effectivement, tout fonctionnait correctement. Maintenant, je devais aller dans les notifications et activer les deux seules notifications EMAIL dont nous aurons besoin :

Nouveau ticket et Ticket clos.

J’ai pu créer un modèle pour avoir un gabarit de l’e-mail avec le logo et les couleurs de notre entreprise, ce qui nous permettrait de personnaliser le contenu de l’e-mail :

Notification de Clôture de Ticket

Numéro De Ticket: ##ticket.id##

Bonjour ##ticket.authors##,

Votre ticket a été résolu avec succès et clôturé.

 	* Description du Ticket : ##ticket.description##

 	* Solution : ##ticket.solution.description##

Si vous avez des questions, n'hésitez pas à nous contacter par mail à support@asconseil.com ou par téléphone au:
05 82 73 03 40

Cordialement,

L'équipe AS Conseil.
[Logo]

Ceci est un e-mail automatisé. Veuillez ne pas répondre.

Après avoir modifié quelques couleurs sur le CSS, tout ce qu’il restait à faire était de résoudre le problème avec l’exécution de l’envoi des notifications. Après avoir consulté les forums, vous pouvez exécuter la tâche « envoyer des emails » avec GLPI ou avec Crontab, malheureusement la méthode GLPI n’est pas très fiable, ce qui signifie que parfois elle s’exécutera et parfois non. Ainsi, j’ai dû programmer la tâche « queuednotification » pour s’exécuter manuellement à l’aide de crontab :

Après les tests, tout fonctionnait correctement.

INVENTAIRES :

C’est l’une des principales préoccupations de mon patron lors du test de GLPI, en raison du fait que nous avons de nombreux clients différents avec différents types d’infrastructures. Puisque notre GLPI n’est pas ouvert à INTERNET, nous devions contourner le fait que chaque client a son propre réseau.

Comme mentionné auparavant, en raison de la nature de notre entreprise, les inventaires doivent être réalisés comme montré dans le schéma précédent. Il y a un serveur OCS qui fonctionne sous LINUX dans le réseau de notre client, ce serveur recueillera toutes les informations d’inventaire puis nous les enverra dans une seule demande.

Pourquoi ne pas utiliser l’inventaire natif de GLPI ?

C’est une bonne question. C’est parce que nous ne travaillons pas avec des clients ou des serveurs locaux, donc même avec notre tunnel IPSEC, nous serions submergés par les demandes de chaque appareil dans tous les réseaux de nos clients tentant de télécharger leur inventaire sur notre GLPI. C’est pourquoi nous avons choisi OCS, car cela nous permet d’avoir un serveur dans le réseau du client et de le gérer directement à partir de là, ensuite le serveur OCS communiquera avec notre GLPI et transférera les inventaires dans une seule demande.

Après que le serveur OCS soit configuré, nous déployons l’agent OCS à l’aide d’une simple GPO, nous inclurons une étiquette pour chaque client sur chaque agent.

Ensuite, après que les demandes soient reçues par notre GLPI, nous attribuerons chaque étiquette à une entité spécifique, complétant ainsi le processus d’inventaire.

Après tout ce travail, j’ai dû rédiger quelques documentations sur la manière d’ouvrir des tickets, de les clôturer et de créer des utilisateurs et des entités. Une fois cela fait, nous avons pu déployer notre GLPI en production.

Aujourd’hui, nous avons plus de 1000 tickets et cela continue de croître à l’intérieur de notre GLPI, donc nous pouvons dire que la migration a été un énorme succès.