WordPress para Servicios Profesionales

Las necesidades para el sitio WEB de una empresa de servicios profesion … http://p.ost.im/p/dudfkR

Apps para un abogado 2.0

Dropbox: Dropbox permite compartir archivos entre ordenadores y disposi … http://p.ost.im/p/dujjLa

Ley de protección de datos – Aviso de Privacidad

Recomendamos a nuestros clientes: a) Tener un aviso en su sitio web sim … http://p.ost.im/p/dPVCww

Aviso De Privacidad

AVISO DE PRIVACIDADKeptos IT Services S.A. de C.V. (En adelante Keptos IT Services), con domicilio en Roche … http://p.ost.im/p/dPHQfd

Configure Exchange E-Mail Server Reverse DNS and MX Records Correctly

By Mike S Collins

If DNS is setup incorrectly, over time your mail server IP will be added to blacklists. Nowadays most E-Mail servers have some kind of spam protection service which in turn means that all your inbound mail will be blocked if you do happen to be listed on a spam blacklist.

In this article I will describe how to correctly configure your MX and reverse DNS records for your mail server. This article is based on an Exchange 2003/2007 server but every other messaging server will follow the same principle.

Assigning an IP address

Starting from the bottom up the first thing you need to do is assign a static external IP address to the internal private address of your mail server. You will need to apply these rules on your firewall to port forward SMTP (port 25) and NAT an external IP address to the internal address of the server.

Something that a lot of administrators forget to do or check is to set the outgoing NAT rule to use the same external IP address created for the inbound rule to the mail server. If this isn’t set, Reverse DNS will not match and in turn your mail server will be listed on blacklists. If your firewall rules are setup correctly the IP address listed on this page should be the same IP address you mapped to the internal private IP address of the mail server.

Create the MX records for your mail server

For the purpose of this example, listed below are all the details of my mail server to help you understand what you need to do.

External IP: 87.22.1.22

E-Mail Domain: domain.com

You will need to be an administrative contact for your External DNS provider for your domain to make these changes. In most cases this can be done through an online control panel through your DNS provider. Failing that on the phone or via E-Mail.

1. The first thing we need to do is create an A record to point to the external IP address mapped on your firewall to the mail server. The host A record can be called any thing but is commonly called «mail». In our example we will create «mail.domain.com» to point to IP address «87.22.1.22»

2. Next we will create an MX record to point to the newly created A record of our mail server.

Within your DNS control panel select «add MX record». Make sure that the host address is the root domain name in our case «domain.com»

Set the FQDN as the A record we just created which in our case is «mail.domain.com».

The lowest property is the most preferred but in our example we will set the priority as 10.

Use NSlookup to check DNS and MX records are applied

It can take up to 48 hours for DNS to propagate but in most cases 12-24 hours. To check our DNS entries are applied and correct we can use nslookup.

1. Open a CMD prompt and type nslookup

2. Type set type=mx

3. Type the domain name which in our case is domain.com.

In our example the output should read as follows if correctly setup:

> domain.com

Non-authoritative answer:

domain.com MX preference = 10, mail exchanger = mail.domain.com

mail.domain.com internet address = 87.22.1.22

Configure Reverse DNS

Reverse DNS is used to verify that the mail server is who it says it is. The recipients mail server will do a reverse lookup to make sure that the IP address of the mail A or host record in DNS is the same as the IP address it is communicating with. Only 1 RDNS entry can be present per IP address.

To do this you will need to contact your ISP to make this entry. You will not be able to do this in your DNS control panel unless your ISP also host your DNS and give you the functionality to add your own RDNS records.

In our case we would contact our ISP and advise that we would like to create an RDNS entry for our IP address 87.22.1.22 which would resolve too mail.domain.com.

Verify Reverse DNS

Again it can take up to 48 hours for DNS to propagate but in most cases 12-24 hours. To verify that the RDNS entries have been added and are correct do the following:

1. Open a CMD prompt.

2. Type Ping -a 87.22.1.22 (This is the external IP address for your mail server. In our case we use our external IP address stated above)

If RDNS is configured correctly the following output will be shown:

C:UsersUser>ping -a 87.22.1.22

Pinging mail.domain.com [87.22.1.22] with 32 bytes of data:

SMTP Banner

Every time a mail server establishes a connection with your mail server it shows its SMTP banner. This banner must be resolvable on the internet and best practice is to have it as your mail host/A record.

Configure SMTP banner Exchange 2003

1. Open Exchange system manager.

2. Expand your administrative group («First administrative group» by default).

3. Expand Servers.

4. Expand YourServerName.

5. Expand Protocals container.

6. Select SMTP container.

7. On the right window, right click the Default SMTP virtual Server (Or the name you set your SMTP Server) and

select Properties.

8. Select the Delivery Tab.

9. Click the Advanced button.

10. Under the Fully-qualified domain name type mail.domain.com (The A/Host record you created in DNS for your mail server)

11. Click OK and OK again to accept the changes

Configure SMTP banner Exchange 2007/2010

1. Open the Exchange management console.

2. Select the Organisation Configuration container.

3. Select Hub Transport container.

4. On the right select the Send Connectors tab.

5. Right click your send connector and select properties.

6. On the General tab under the Set the FQDN this connector will… type the A record domain name you created. Which in our case ismail.domain.com. Click OK.

7. Under the Server Configuration container click the Hub Transport container.

8. In the Right window Select the properties of the Receive Connector under Receive Connectors tab.

9. On the General tab under the Set the FQDN this connector will… type the A record domain name you created. Which in our case ismail.domain.com. Click OK

To verify these changes we can use telnet to view the output upon establishing a connection on port 25 to our mail server. Use the following steps to do this:

1. Open a CMD prompt

2. Type Telnet mail.domain.com 25.

The output you see should look something like this and contain your A record of your mail server:

220 mail.domain.com Microsoft ESMTP MAIL Service ready at Sun, 28 Feb 2

010 17:51:20 +0000

If you use an edge server or a SPAM filter appliance like a Barracuda the SMTP banner will have to be set on this device/server.

Check to see if your mail server is on spam lists and/or an open relay

A great website to use to check your MX records, RDNS, check if your mail server is an open relay and check to see if you are listed on spam lists is www.mxtoolbox.com. This is a great site and one to keep in your favourites.

Following these guide lines will successfully and correctly configure mail routing to and from your mail server. The next step is too secure and ensure your mail server is not an open relay. I will be writing a separate article dedicated to this in the near future.

If you would prefer to not experience the stress in looking after and maintaining an Exchange server environment you may choose a hosted exchange server solution instead.

Mike Collins has over 10 years experience in computing and is a senior IT Consultant at Sphere IT Consulting

Article Source: http://EzineArticles.com/?expert=Mike_S_Collins

La carga de la cola de peticiones

Referencia

Link Acrobat

Para comenzar esta parte, debe tenerse en cuenta que los modos de carga de peticiones son acumulativos. Cada método tiene sus ventajas y desventajas. A continuación, seleccione el modo o modos de suministro de los peticiones/billetes de la cola/línea a sus necesidades y sus limitaciones.GLPI dispone de tres modos de carga de la cola de las entradas:

Por el solicitante en la interfaz (el perfil de post-sólo que sin la autenticación o anónima).
Por un técnico (llame al centro de operaciones, por ejemplo).
Para la recuperación de los correos en un buzón para su conversión a solicitudes de asistencia.
1. Por la interfaz de usuario

Esto es para permitir al solicitante a escribir su propia solicitud de ayuda.

Utilización de la interfaz de entrada

GLPI integra a la perfección este procedimiento al proporcionar un formulario de entrada de solicitudes. Este formulario está disponible para todos los usuarios autenticados una vez que el perfil de post-sólo que se les asignen. La definición de este perfil se detalla en los perfiles de capítulo.

Por supuesto, es posible modificar este perfil o crear otros nuevos con el mismo tipo de operación con variaciones más o menos importantes. En todos los casos estos perfiles, se simplificará el tipo de interfaz.

En la configuración por defecto, GLPI ofrece post-solo perfil como perfil predeterminado.Reglas raíz regla para la asignación de autorizaciones para un usuario le da derechos por defecto en la entidad raíz. Y sin cambiar la configuración de GLPI, cualquier usuario autenticado puede solicitar la ayuda.

Para probar este método:

Inicie sesión en GLPI con una cuenta de usuario con el perfil de una entidad posterior a la única, por lo menos.

Las cuentas por defecto, puede utilizar el nombre de usuario / contraseña post-only/postonly.

La página de inicio presenta un resumen estadístico de sus entradas, entradas distribuidas por los Estatutos.

Para ver las entradas, haga clic en el menú Entradas.

También puede acceder a la lista de entradas con un estado dado por hacer clic en la redacción de este estatuto en la tabla en la página principal.

Para crear un nuevo ticket en la página principal, haga clic en Crear un ticket en el encabezado de la tabla.

Para crear un nuevo ticket de la página que contiene la lista de entradas, haga clic en el botón Agregar.
La interfaz de entrada le permite especificar los siguientes campos:

De emergencia (Muy alto / alto / medio / bajo / muy bajo): Este campo es a menudo mal utilizada por los solicitantes. Da igual que no lo use y no pesan lo soliciten, o que tienden a considerar que su aplicación es siempre muy urgente!

Seguido por email (No / Sí): Este parámetro permite al usuario solicitar que se les notificará por correo de las distintas etapas de tramitación de la solicitud.

Los mensajes enviados durante las diversas etapas en la vida de una solicitud de ayuda se gestiona de la notificación de la demanda.

Email: Este campo se llena automáticamente por correo electrónico si el solicitante es conocida en los estados financieros básicos. De lo contrario, este campo es un campo de entrada que permite que el solicitante indique su correo electrónico.

El billete incluye: Este campo proporciona los elementos del inventario en relación con el solicitante, en el que podrán solicitar la ayuda.

Estos elementos se definen en la configuración del perfil post-solamente.

Tipo (Incidentes / petición): Esta distinción es consecuencia directa de la integración de ITIL V1 en GLPI. Para simplificar la distinción entre los dos términos, un incidente es un problema o un fracaso y una solicitud corresponde a una menor tensión de bloqueo como un comando de nuevos equipos, por ejemplo. Un incidente de solución de problemas requiere un tiempo de procesamiento de solicitud de llamada de acuerdo a un circuito diferente.

Categoría: GLPI ofrece la posibilidad de definir las categorías de entradas. Estas clases se realizan en el menú de configuración – título. Categorías se gestionan entidad (con posibilidad de ampliar el subárbol). Es posible que la estructura de las categorías de una estructura de árbol.

Es posible hacer que el campo requiere. Este ajuste es en el menú Configuración – pestaña General, de apoyo.

Esta noción es muy importante ya que permite clasificar las solicitudes de asistencia de su creación y la aplicación de tratamientos mediante reglas. A continuación, puede asignar automáticamente entradas directamente relacionados con determinadas categorías, el técnico o un grupo de técnicos encargados del campo.

Título: Este campo es obligatorio. Se define el nombre de la entrada en la lista de las solicitudes de asistencia y haciendo clic en el nombre se abre el archivo de la solicitud de asistencia.

Descripción: Este campo de entrada se utiliza para describir la solicitud. Puede ser obligatoria.

Archivo (16 millones de max): Este campo le permite asociar un archivo con una solicitud de asistencia.

Confirmar la creación del billete haciendo clic en el botón Enviar mensaje.

Anónimo boleto abierto

Se trata de ofrecer la opción de ingresar una solicitud de asistencia sin tener que autenticarse primero. Este método utiliza una forma especial en http://ip_serveur/glpi/front/heldesk.html.

La forma es simple y consiste en menos de los campos de entrada por defecto. Helpdesk.html página es un ejemplo del uso de aplicaciones en modo anónimo. Este formulario se puede, por supuesto, personalizado con la edición del código de la página.

Por favor, tenga en cuenta esta forma no contiene todos los campos disponibles en el formulario de entrada por defecto de post-sólo perfil. Por ejemplo, si usted hace el tipo de billete es necesario, la creación de la solicitud de asistencia no será de forma nativa porque la forma no devuelve esta información. Se trabajará sobre el contenido de este formulario para agregar información o la categoría de facultativo de billete.

El modo de alimentación es el problema del seguimiento anónimo de las solicitudes de asistencia ya que estas peticiones no son de forma nativa asociada a una cuenta de usuario de base de datos o un objeto del inventario.

2. Por un técnico

En este modo de alimentación es un técnico que informa a los campos de entrada diferentes.Este uso está vinculado a los perfiles de la interfaz de tipo estándar.

Este modo de operación corresponde a una organización con las aplicaciones centralizadas.El técnico recibe las solicitudes con mayor frecuencia por teléfono, e ingresarlos en la interfaz.

Como técnico debe tener un perfil para este tipo de interfaz estándar. El perfil predefinido que mejor se adapte a esta función es el perfil de administrador. En la medida en que no hay ninguna cuenta por defecto asociado con este perfil, se puede utilizar el GLPI cuenta para descubrir la interfaz de entrada de las aplicaciones (la principal diferencia es la falta de autorización para eliminar el perfil seguido admin).

Inicie sesión en GLPI GLPI con la cuenta (login / password: GLPI / GLPI).
Entra en el menú Ayuda – Tickets.
La lista de entradas sin resolver muestra.

Haga clic en el botón Agregar.
Rellene el formulario de solicitud de asistencia:
Abierto: Este campo especifica la fecha de apertura de la entrada. El campo se rellena previamente con la fecha y hora del servidor. La entrada es a través de tres campos de entrada: Fecha de la (una función de calendario se encuentra disponible para la ayuda de entrada), las horas y minutos.

Plazo: Este campo le permite fijar un plazo para el procesamiento de la solicitud de asistencia. Se calcula de forma automática si una regla asociada con el billete de un SLA.

Solicitante Sección

La solicitud puede provenir de:

De un usuario: encontrar a la demandante en la lista de usuarios de GLPI:

Introduzca las primeras letras del nombre del solicitante en el primer campo.
La lista de nombres que contienen las letras introducidas muestra.

Seleccione el nombre del solicitante.

Si el usuario tiene derecho a varias entidades, especifica que la solicitud. El billete estará bien posicionado en esta entidad. Si el usuario tiene derechos como una entidad, esta acción es automática.

Rellene los campos siguientes:
Seguido por el e-mail cuando va seguida de correo electrónico está activada (menú Configuración – Notificaciones), es posible proponer un seguimiento de las entradas por correo electrónico.

Email: Este campo contiene la dirección de correo electrónico del solicitante. Que se rellena automáticamente si la información está presente en la forma del usuario. De lo contrario, es posible introducir la dirección de correo electrónico del solicitante de utilizar el control de la aplicación por correo.

Si el usuario no está presente en la cuenta de GLPI base de datos y una conexión a un directorio LDAP definido, haga clic en el botón Importar un usuario para acceder a la ventana para importar usuarios desde un directorio LDAP.

De un grupo: Seleccione el grupo demandante en la lista desplegable de los grupos.

Sección Visor

GLPI propone nombrar observadores para que el billete se está creando. Un observador se le informará de la vida de la solicitud, sin ser capaz de trabajar en él. Un observador puede ser una cuenta de usuario de base de datos o un grupo definido en GLPI. El principio es el mismo que la entrada para el solicitante de campo.

Atribuye a la Sección

Este campo se usa para designar a la persona o grupo de personas que van a actuar en la presente solicitud de ayuda. El funcionamiento es el mismo que el solicitante o el observador.Sin embargo, también es posible asignar una solicitud de asistencia a un proveedor fuera nombrado en el menú de Gestión – Proveedores. Esto permitirá a informar directamente a un servicio, cuando su intervención sea considerada necesaria por el técnico que llevó a la aplicación.

Para cada una de estas tres categorías de actores, es posible agregar usuarios y grupos o proveedores a los responsables de la entrada. La solicitud inicial del formulario de entrada no puede introducir un usuario y / o de grupo. Cuando la solicitud se valida, es posible añadir más usuarios y grupos (o proveedores para la última categoría de actores) que desee.

Otros campos

Estado (Nuevo / En curso (atribuido) / curso (planificado) / Pendiente / Resuelto / Cerrado): Este campo especifica el estado de la entrada. Esta lista es una lista cerrada que no se puede cambiar. Cada valor corresponde a una etapa de la tramitación de la solicitud. El valor por defecto cuando se crea una nueva demanda. Si el billete se asigna cuando se crea (ya sea manualmente oa través de una regla), el estado cambia a En curso (con atributos).

La capacidad de mover un billete de un estado a otro se define el perfil en el ciclo de vida de la sección de entradas interfaz estándar tipo de perfil. Por ejemplo, un perfil dedicado a supervisar la labor de los equipos de apoyo tiene el derecho de cambiar el estado de una aplicación sin tener que pasar por Clos resueltos antes.

De emergencia: (Muy alto / alto / medio / bajo / muy bajo): Este valor se define por el solicitante. Desde la perspectiva del usuario, que sustituye la noción de prioridad.

Impacto: (Muy alto / alto / medio / bajo / muy bajo): este valor se establece por el técnico. Sólo una persona a cargo de los billetes de procesamiento es capaz de medir el alcance de un incidente o una solicitud sobre el funcionamiento de la estructura.

Prioridad: (Mayor / Muy alto / alto / medio / bajo / muy bajo): Este campo es calculado a partir de los dos campos anteriores. Este cálculo se basa en la matriz definida en el menú Configuración – General, ficha de asistencia técnica.

La prioridad es que fuera de la matriz y por lo tanto no se puede acceder por esta forma para las personas cuyo perfil les permita.

Tipo (Incidentes / solicitud): Este concepto viene directamente de ITIL V1. Un incidente es algo que requiere una intervención de reparación, mientras que una aplicación es algo menos de bloqueo.

ITIL proporciona un concepto adicional no implementado en esta versión de GLPI: la noción de problema. Cuando un incidente se repite al menos dos veces, ya no se habla de un incidente, pero un problema. La solución debe centrarse en la causa de los incidentes de modo que no se repitan.

Tiempo total: Este campo se utiliza para cuantificar el tiempo empleado en el procesamiento de esta solicitud. Este período se añadirá a tiempo dedicado a tareas relacionadas con el billete. Será en la ficha Costos cuando el billete se valida. Esta ficha se utiliza para valorar el pasado.

Título: Este campo es obligatorio, establece el nombre de la lista de solicitudes de entradas.Debe ser lo más explícito posible. (No es simplemente «mail», pero «el problema de enviar un mensaje al exterior con la última courrielleur.» Este lenguaje se toma como la base de la pregunta de si desea inyectar este problema y su solución en la base de datos conocimiento o en el FAQ.

Descripción: Este campo permite una descripción completa del problema.

Archivo (16 millones de max): Este campo le permite adjuntar un documento a una solicitud.

Material: de acuerdo a la definición del perfil se utiliza aquí es posible visualizar los elementos del presente inventario en la base de datos (Sección Oficial), que designa el tipo de objeto en primer lugar, a continuación, seleccione la objeto de la lista. Si los artículos del inventario que el solicitante como usuario, será la posibilidad de especificar que la aplicación (parte de mi material).

Fuente de aplicación: Este campo le permite especificar el origen de la solicitud. La lista de las fuentes se mantiene en el menú Configuración – Encabezados, sección de soporte, Tabla de origen de la solicitud. Una fuente predeterminado está establecido para las entradas de la interfaz GLPI y otro para las aplicaciones de recogida a través de un encabezado de correo.

Categoría: Este campo define el tipo de aplicación. Las clases se realizan en el menú de configuración – Encabezados, sección de soporte. Las categorías son gestionados entidad (no se olvide de la posición de la entidad que desee antes de la creación de categorías), y una estructura de árbol. Es posible que el mandato de la designación de una categoría para cada billete. Esta información puede ser una fuente muy útil para implementar procesos automatizados mediante reglas.

Solicitud de validación: GLPI ofrece ahora la oportunidad de validar una solicitud de asistencia. La persona encargada de validar el billete deberá ser designado entre el perfil de los usuarios que les autorice, y con este perfil de la entidad de la entrada.

Entradas relacionadas

GLPI ofrece entradas para que participen:

Haga clic en el vínculo Agregar. GLPI ofrece dos opciones:
Relacionado con Ticket ID: Este campo es un campo de información que se asocia a ningún tratamiento. Escriba el identificador de la entrada a asociarse con el billete actual.

El vínculo es recíproco: el identificador de los enlaces de entrada actual aparecerá en el ticket correspondiente.

Venta de entradas duplicadas ID: Esta función le permite vincular el ticket con el billete actual con ID introducido aquí. Cuando una solución es capturado en una de las entradas, que se copia automáticamente a la solución del otro boleto.

Confirmar la creación del billete haciendo clic en el botón Agregar.

3. Por los robots

GLPI ofrece una solución a la energía de la última fila de entradas: el uso de bots.

El principio de los robots es para consultar el contenido de un buzón de mensajes y convertir cada entrada de mensajes. Así que no hay ninguna entrada en este caso a realizar. El demandante prepara su pedido en su courrielleur habitual y envía su mensaje a una dirección definida.

Usted puede definir los encabezados tanto como te gusta. Será posible usar varios buzones para llevar a cabo una evaluación inicial de las aplicaciones. En este caso, es posible organizar las cajas de las entidades, por categorías de aplicaciones, etc. Así, por una solicitud de impresoras: escribir en el cuadro de dépannage_imprimantes@masociete.com …

Para configurar una bots

Debe tener derechos de configuración, a continuación, utiliza una cuenta que tiene un perfil super-admin.

Conectar con la cuenta de GLPI.

Vaya al menú de configuración – coleccionistas.
Haga clic en el botón Agregar.
Rellene los campos:

Nombre: Este campo define el nombre de los robots. Este nombre debe ser explícito, ya que puede ser utilizado como criterio en las normas de procesamiento de billetes.

Cuando los robots son por lo menos creó una nueva categoría de normas en la pantalla (menú Administración – Reglamento). Vea a continuación la definición de las normas relacionadas con el servicio de asistencia.

Server: Este campo especifica la dirección del servidor de correo.

Opciones de conexión: los campos de abajo se utilizan para definir la forma en GLPI se conectará al servidor de correo.

IMAP / POP: Este campo controla si la conexión es para recuperar los mensajes y eliminarlos del buzón de correo (POP) o si los mensajes deben ser guardados en la caja después de ser recuperado (modo IMAP).
SSL: Este campo le permite definir si la conexión está asegurada por SSL (Secure Sockets Layers).
TLS / TLS-NO: Este campo le permite definir si la conexión es segura con TLS (Transport Layer Security).
NO-VALIDATE-CERT/VALIDATE-CERT: Este campo controla si la verificación de la validez del certificado es necesario para conectar al servidor de correo.
Carpeta de mensajes (opcional, por lo general INBOX): Este campo define la carpeta donde se recuperan los mensajes.

Puerto (opcional): Este puerto depende del modo de funcionamiento de la conexión (POP o IMAP) y la seguridad de esta conexión o no. Esto le da: IMAP (puerto 143), IMAPS (puerto 993), POP (puerto 110) y POPS (puerto 995).

Cadena de conexión: campo de cadena de conexión se calcula a partir de los valores de los campos anteriores.

ID: Este campo es el identificador de la cuenta que tenga permisos de lectura en el buzón.

Contraseña: Este campo le permite introducir la contraseña asociada a la cuenta anterior.

Tamaño máximo del archivo importado por el colector: Este campo limita el tamaño de los archivos adjuntos a los mensajes recuperados del buzón de correo por los robots.

Comentarios: Este campo de comentarios puede ayudar a explicar el uso inicial de este colector.

Validar la creación haciendo clic en el botón Agregar.

4. Ventajas y desventajas de tres modos de potencia

A fin de comparar diferentes soluciones, se debe indicar los criterios para la comparación:

La facilidad de uso para el solicitante.
La facilidad de uso por los equipos de apoyo.
La facilidad de implementación y operación.
La facilidad de uso para el solicitante

A través de este criterio, también debe leer el nivel de aceptación del cambio en los hábitos y las nuevas restricciones impuestas.

Dos patrones dietéticos emergen favoritos aquí: alimentación mails colector y la incautación de un técnico después de una llamada telefónica. Estos dos modos son de poca dificultad para el solicitante. Un pequeño esfuerzo de la formulación de la solicitud aún debe ser hecha en la solicitud por correo, pero esto es a menudo una herramienta de control.
Por el contrario, el uso de la modalidad en línea formulario de entrada trae muchas limitaciones para el usuario:
Conectarse a la herramienta, posiblemente con la necesidad de una nueva contraseña. El uso de una fuente externa de autenticación (o SSO) es una necesidad absoluta en términos de aceptación de la restricción.

Formalizar la solicitud: El requisito para el usuario para describir su problema no es a menudo con mucha experiencia. Además, dependiendo de la configuración del formulario de solicitud, los campos de entrada obligatoria puede ser desconcertante para los solicitantes que deseen hacer clic rápidamente sobre el envío del mensaje.

Un último obstáculo es la necesidad de proporcionar una conexión con el servidor GLPI.

La facilidad de uso por los equipos de apoyo

Este criterio es el de ganar, ya que presagia una mayor eficiencia en la tramitación de solicitudes.

El uso de robots tiene un nivel de complejidad de las operaciones superiores a otras formas de poder: de hecho, en un mensaje de que no hay formalidad o requisito para que el solicitante pueda formular como un una forma de permitir la automatización de sus operaciones. Esta alimentación impone una importante labor de reformulación y la pérdida de tiempo.

Todavía es importante señalar que GLPI es capaz de recibir un mensaje de asociar los tiquets generados al usuario la dirección de correo electrónico que envía el mensaje.

El poder de la forma de entrada en modo anónimo puede acercarse a este nivel de complejidad de las operaciones.

El uso de la forma por el modo en línea el solicitante es un compromiso interesante, ya que permite, en función de los bienes incautados (la parte conocida), para realizar un tratamiento previo, como una asignación automática del billete de acuerdo con la tipo de aplicación. El solicitante también puede asociarse a su reclamo a un elemento de su propio inventario.
Por último, la entrada de solicitud por el técnico hace una reformulación directa y la gestión inmediata de la demanda. Este tipo de dieta es la que genera la menor cantidad de errores de gestión.
La facilidad de implementación y operación

Casi no hay restricción en el uso de colectores y en las formas de correo de entrada por el usuario.

Sin embargo, la introducción de una serie de aplicaciones para la entrada por un técnico coloca una organización muy pesada para poner en práctica y puede ser considerado solamente para estructuras muy grandes. Disponibilidad debe ser permanente en los rangos definidos.

En conclusión

Antes de configurar uno o más circuitos de la línea de alimentación de las entradas, usted comenzará a reflexionar sobre las expectativas de sus clientes y cómo hay que responder.

Su respuesta, por supuesto, una combinación de varias soluciones. En este caso, tendrá que definir lo que los casos de uso corresponden a cada uno de los circuitos.

Su análisis se basa en estos tres criterios, pero también puede ser complementado con criterios basados ​​en la formación de usuarios, los costos asociados con las alternativas ….

El interés de esta parte es de vislumbrar las implicaciones y limitaciones que la aplicación de GLPI tendrá en el funcionamiento de su estructura.

Introducción – Servicio de Asistencia – GLPI

Referencia

Introducción

Para empezar, una breve definición de lo que puede ser el Servicio de Asistencia (o Help-Desk o Mesa de Ayuda).

Helpdesk (servicio de ayuda en francés) con el mismo término abarca varios conceptos: en primer lugar puede ser el organismo responsable de la asistencia de los usuarios, pero puede ser también (como nos interesa aquí) de la herramienta necesaria para procesar estas solicitudes de asistencia.

La función de asistencia GLPI se expandió ampliamente desde las versiones más recientes.La implementación de ITIL V1 en la versión 0.80 y versiones posteriores de la implementación de ITIL en las siguientes versiones de GLPI lo convierten en uno de las herramientas del servicio de asistencia más avanzada que existe.

Las solicitudes de asociación para la asistencia a los artículos del inventario también se sigue para distinguir GLPI otras herramientas gratuitas disponibles en el mercado, permitiendo el seguimiento de las solicitudes por artículo de inventario, por solicitud …

El ámbito funcional de GLPI en la mesa de ayuda puede finalmente hacer un boleto de seguimiento en otros campos de la informática: GLPI se presta muy bien para hacer frente a las solicitudes de otras actividades de apoyo como el general significa, por ejemplo.

El enfoque de este capítulo tiene por objeto permitir que den un paso a paso, poco a poco en la creación de su solución de helpdesk. Después de un recorrido por las diversas funciones que ofrece por GLPI, se recomienda encarecidamente a tomar el tiempo para definir su organización y definir el papel de cada actor con el fin de configurar la herramienta de acuerdo a sus aspiraciones.

Es esencial tener en cuenta que el establecimiento de una solución de asistencia permite una actualización sobre el funcionamiento del soporte de TI, y que a menudo hay una oportunidad para aclarar los circuitos y los papeles. Esta aclaración también puede afectar el nivel de toda la empresa, siendo una oportunidad para hacer una formalización de las solicitudes de asistencia. Más allá de la implementación de la herramienta, será preciso establecer un plan de apoyo para definir las aplicaciones de circuitos, la lista de actores y sus roles. Todo esto también debe ir acompañada de un plan de comunicación para explicar el proceso y evitar así reclamaciones «salvaje» que a menudo son una fuente de la interrupción de la audiencia.

Cabe señalar que el nuevo funcional surgido desde la versión 0.80 este trabajo incluye el análisis y la comunicación, incluso si usted ya usa GLPI en versiones anteriores. Un ejemplo ilustra la necesidad urgente: ahora que ITIL puede incluir solicitudes de asistencia ya no están cerradas por el técnico encargado de la aplicación, pero el propio demandante a la luz de la solución propuesta desarrollada por el técnico.

El establecimiento de una herramienta de servicio de asistencia está altamente estructurado para el funcionamiento de la empresa y no se puede hacer a la ligera. Este desarrollo debe ser considerado al más alto nivel de la estructura y no puede ser simplemente un miembro del equipo.

Es muy común encontrar estudiantes foros de preguntas relacionadas con haber tenido la tarea de crear una solución de inventario de los equipos informáticos y una herramienta para el seguimiento de las solicitudes de asistencia durante un curso de el verano. ¿Qué puede hacer la legitimidad de un interno, por definición, fuera de la estructura, para imponer nuevos procedimientos para el personal de TI, sino también para toda la empresa?

L’alimentation de la file de tickets

Pour débuter cette partie, il convient de préciser que les différents modes d’alimentation de la file de tickets sont cumulatifs. Chacune de ces méthodes présente des avantages et des inconvénients. Il vous appartiendra ensuite de choisir le ou les modes d’alimentation de la file de tickets selon vos besoins et vos contraintes.

GLPI offre trois modes d’alimentation de la file de tickets :

• Par le demandeur, dans l’interface (profil post-only ou anonyme sans authentification).
• Par un technicien (fonctionnement en centre d’appel par exemple).
• Par la récupération de mails dans une boîte aux lettres en vue de leur conversion en demandes d’assistance.

1. Par l’utilisateur dans l’interface

Il s’agit ici de permettre au demandeur de rédiger lui-même sa demande d’assistance.

Utilisation de l’interface de saisie

GLPI intègre parfaitement ce mode opératoire en proposant un formulaire de saisie des demandes. Ce formulaire est accessible à tous les utilisateurs authentifiés dès lors que le profil post-only leur est attribué. La définition de ce profil est détaillée dans le chapitre Les profils.

Il est bien sûr possible de modifier ce profil ou d’en créer d’autres ayant ce même type de fonctionnement avec des variantes plus ou moins importantes. Dans tous les cas ces profils seront du type Interface simplifiée.

Dans la configuration par défaut, GLPI propose le profil post-only comme profil par défaut. La règle Root des Règles d’affectation d’habilitations à un utilisateur donne par défaut des droits sur l’Entité racine. Ainsi sans modifier la configuration de GLPI, n’importe quel utilisateur authentifié peut déposer une demande d’assistance.

Pour tester ce mode :

 Connectez-vous à GLPI avec un compte utilisateur ayant le profil post-only sur une entité au moins.

Parmi les comptes par défaut, vous pouvez utiliser le login/mot de passe post-only/postonly.

Votre page d’accueil vous présente une synthèse statistique de vos tickets, répartis par Statuts des tickets.

Pour visualiser vos tickets, cliquez sur le menu Tickets.

Vous pouvez également accéder à la liste des tickets ayant un statut donné en cliquant sur le libellé de ce statut dans le tableau de la page d’accueil.

 Pour créer un nouveau ticket à partir de la page d’accueil, cliquez sur le lien Créer un ticket dans le titre du tableau.

 Pour créer un nouveau ticket à partir de la page contenant la liste des tickets, cliquez sur le bouton Ajouter.

L’interface de saisie permet de préciser les champs suivants :

Urgence (Très haute/Haute/Moyenne/Basse/Très basse) : ce champ est très souvent mal utilisé par les demandeurs. Soit ils ne l’utilisent pas et ne pondèrent ainsi pas leur demande, soit ils ont tendance à considérer que leur demande est systématiquement très urgente !

Suivi par courriel (Non/Oui) : ce paramètre permet à l’utilisateur de demander à être informé par messagerie des différentes étapes du traitement de sa demande.

Les messages émis lors des différentes étapes de la vie d’une demande d’assistance sont gérés dans la partie notification de l’application.

Courriel : ce champ est automatiquement rempli si l’email du demandeur est connu dans la base des comptes. Dans le cas contraire, ce champ devient un champ de saisie qui permet au demandeur d’indiquer son email.

Le ticket porte sur : ce champ propose les éléments de l’inventaire en relation avec le demandeur, à propos desquels il va pouvoir déposer une demande d’assistance.

Ces éléments sont définis dans la configuration du profil post-only.

Type (Incident/Demande) : cette distinction est directement issue de l’intégration de ITIL V1 dans GLPI. Pour simplifier la distinction des deux termes, un Incident correspond à un problème ou une panne et une Demande correspond à une sollicitation moins bloquante comme une commande de nouveau matériel par exemple. Un Incident appelle un dépannage alors que la Demande appelle un traitement suivant un circuit différent.

Catégorie : GLPI offre la possibilité de définir des catégories de tickets. Ces catégories sont gérées dans le menu Configuration – Intitulés. Les catégories sont gérées par entité (avec possibilité d’étendre à la sous-arborescence). Il est possible de structurer les catégories de manière arborescente.

Il est possible de rendre ce champ obligatoire. Ce paramétrage se fait dans le menu Configuration – Générale, onglet Assistance.

Cette notion est très importante car elle permet de classifier les demandes d’assistance dès leur création et de leur appliquer des traitements à l’aide de règles. Vous pourrez ainsi assigner automatiquement les tickets relatifs à certaines catégories directement au technicien ou au groupe de techniciens en charge du domaine.

Titre : ce champ est obligatoire. Il définit le nom du ticket dans la liste des demandes d’assistance et un clic sur ce nom ouvre la fiche de la demande d’assistance.

Description : ce champ de saisie permet de décrire la demande. Il peut être rendu obligatoire.

Fichier (16 Mio max) : ce champ permet d’associer un fichier à une demande d’assistance.

 Validez la création du ticket en cliquant sur le bouton Envoyer message.

Ouverture de ticket anonyme

Il s’agit ici d’offrir la possibilité de saisir une demande d’assistance sans avoir à s’authentifier au préalable. Cette méthode fait appel à un formulaire spécifique à l’adresse http://ip_serveur/glpi/front/heldesk.html.

Le formulaire est simplifié et comporte par défaut moins de champs de saisie. La page helpdesk.html est un exemple d’utilisation des demandes en mode anonyme. Ce formulaire peut bien entendu être personnalisé en modifiant le code de la page.

Attention ce formulaire ne contient pas tous les champs disponibles par défaut dans le formulaire de saisie du profil post-only. Ainsi par exemple, si vous rendez la catégorie de ticket obligatoire, la création de la demande d’assistance ne pourra pas se faire nativement car le formulaire ne renvoie pas cette information. Il faudra intervenir sur le contenu du formulaire pour ajouter cette information, ou bien rendre la catégorie de ticket facultative.

Le mode d’alimentation anonyme pose le problème du suivi des demandes d’assistance car ces demandes ne sont nativement pas associées à un utilisateur de la base de comptes ni à un élément de l’inventaire.

2. Par un technicien

Dans ce mode d’alimentation, c’est un technicien qui renseigne les différents champs de saisie. Cette utilisation est liée aux profils de type interface standard.

Ce mode de fonctionnement correspond à une organisation avec centralisation des demandes. Le technicien reçoit les demandes le plus souvent par téléphone, et les saisit dans l’interface.

En tant que technicien vous devez pour cela avoir un profil du type Interface standard. Le profil prédéfini le plus adapté à cette fonction est le profiladmin. Dans la mesure où il n’existe aucun compte par défaut associé à ce profil, vous pourrez utiliser le compte glpi pour découvrir l’interface de saisie des demandes (la différence principale est l’absence d’autorisation de supprimer des suivis pour le profil admin).

 Connectez-vous à GLPI avec le compte glpi (login/mot de passe : glpi/glpi).

 Placez-vous dans le menu Assistance – Tickets.

La liste des tickets non résolus s’affiche.

 Cliquez sur le bouton Ajouter.

 Complétez la fiche de demande d’assistance :

Ouvert le : ce champ permet de spécifier la date d’ouverture du ticket. Le champ est prérenseigné avec la date et l’heure du serveur. La saisie se fait au travers de trois champs de saisie : La date (une fonction de calendrier est disponible pour l’aide à la saisie), l’heure et les minutes.

Echéance : ce champ permet de définir une date butoir de traitement pour la demande d’assistance. Il est calculé automatiquement si une règle associe le ticket à une SLA.

Section Demandeur

Une demande peut provenir :

D’un utilisateur : pour retrouver le demandeur dans la liste des utilisateurs de GLPI :

 Saisissez quelques lettres du nom du demandeur dans le premier champ.

La liste des noms contenant les lettres saisies s’affiche.

 Sélectionnez le nom du demandeur.

Si l’utilisateur possède des droits sur plusieurs entités, précisez sur laquelle porte la demande. Le ticket sera ainsi positionné dans cette entité. Si l’utilisateur n’a des droits que sur une entité, cette action est automatique.

 Renseignez les champs suivants :

Suivi par courriel : lorsque les Suivis par courriel sont activés (menu Configuration – Notifications), il est possible de proposer un suivi du ticket par courriel.

Courriel : ce champ contient l’adresse mail du demandeur. Il est automatiquement renseigné si l’information est présente dans la fiche de l’utilisateur. Dans le cas contraire, il est possible de saisir l’adresse mail du demandeur pour pouvoir utiliser le suivi de la demande par mail.

Si l’utilisateur n’est pas présent dans la base de comptes de GLPI et qu’une connexion vers un annuaire LDAP est définie, cliquez sur le boutonImporter un utilisateur pour accéder à la fenêtre d’importation des utilisateurs à partir d’un annuaire LDAP.

D’un groupe : sélectionnez le groupe demandeur dans la liste déroulante des groupes.

Section Observateur

GLPI propose de désigner des observateurs pour le ticket en cours de création. Un observateur sera informé de la vie de la demande d’assistance sans pouvoir intervenir sur celle-ci. Un observateur peut être un utilisateur de la base de comptes ou un groupe défini dans GLPI. Le principe de saisie est le même que pour le champ Demandeur.

Section Attribué à

Ce champ sert à désigner la personne ou le groupe de personnes qui auront à intervenir sur cette demande d’assistance. Le fonctionnement est le même que pour le Demandeur ou l’Observateur. En revanche, il est également possible d’attribuer une demande d’assistance à un fournisseur externe désigné dans le menu Gestion – Fournisseurs. Il sera ainsi possible d’informer directement un prestataire de service dès lors que son intervention est jugée nécessaire par le technicien qui saisit la demande.

Pour chacune de ces trois catégories d’acteurs, il est possible de cumuler les utilisateurs et les groupes, voire les fournisseurs pour les personnes en charge du ticket. Le formulaire de saisie initiale de la demande permet de ne saisir qu’un utilisateur et/ou un groupe. Lorsque la demande est validée, il est possible de rajouter autant d’utilisateurs et de groupes (voire de fournisseurs pour la dernière catégorie d’acteurs) que vous le souhaitez.

Autres champs

Statut (Nouveau/En cours (Attribué)/En cours (Planifié)/En attente/Résolu/Clos) : ce champ permet de spécifier l’état d’avancement du ticket. Cette liste est une liste finie qu’il n’est pas possible de modifier. Chacune des valeurs correspond à une étape du traitement de la demande. Par défaut la valeur lors de la création d’une demande est Nouveau. Si le ticket est attribué lors de sa création (soit manuellement soit au travers d’une règle), le statut passe alors à En cours (Attribué).

La possibilité de passer un ticket d’un statut à un autre est définie par profil, dans la section Cycle de vie des tickets des profils de type interface standard. Ainsi par exemple seul un profil dédié à la supervision du travail des équipes d’assistance aura le droit de faire passer le statut d’une demande à Clos sans qu’il soit passé par Résolu avant.

Urgence : (Très haute/Haute/Moyenne/Basse/Très basse) : cette valeur est définie par le demandeur. Du point de vue de l’utilisateur, elle remplace la notion de priorité.

Impact : (Très haut/Haut/Moyen/Bas/Très bas) : cette valeur est définie par le technicien. Seule une personne en charge du traitement des tickets est capable de mesurer la portée d’un incident ou d’une demande sur le fonctionnement de la structure.

Priorité : (Majeure/Très haute/Haute/Moyenne/Basse/Très basse) : ce champ est calculé à partir des deux champs précédents. Ce calcul se fait à partir de la matrice définie dans le menu Configuration – Générale, onglet Assistance.

La priorité Majeure n’existe qu’en dehors de la matrice et ne peut donc être accessible que par ce formulaire pour les personnes dont le profil les y autorise.

Type (Incident/Demande) : cette notion est directement issue de ITIL V1. Un incident est quelque chose qui appelle une intervention de dépannage, tandis qu’une demande est quelque chose de moins bloquant.

ITIL prévoit une notion supplémentaire non implémentée dans cette version de GLPI : la notion de problème. Lorsqu’un incident se reproduit au moins deux fois, on ne parle plus d’incident mais de problème. La solution doit alors s’attacher à la cause des incidents afin qu’ils ne se reproduisent plus.

Durée totale : ce champ permet de quantifier le temps passé sur le traitement de cette demande. Cette durée s’ajoutera aux temps passés sur les tâches associées au ticket. Il se retrouvera dans l’onglet Coûts du ticket lorsqu’il sera validé. Cet onglet sert à valoriser les temps passés.

Titre : ce champ est obligatoire, il définit le nom du ticket dans la liste des demandes. Il doit donc être le plus explicite possible. (ne pas se contenter de « messagerie », mais plutôt « problème d’envoi de message vers l’extérieur avec dernière version du courrielleur ». Ce libellé sera repris comme base de question si vous souhaitez injecter ce problème et sa solution dans votre base de connaissances, voire dans la FAQ.

Description : ce champ permet une description complète du problème rencontré.

Fichier (16 Mio max) : ce champ permet de joindre un document à une demande.

Matériel : en fonction de la définition du profil utilisé, il est ici possible d’afficher les éléments de l’inventaire présents dans la base de données (partieGénéral), en désignant d’abord le type d’objet, puis en sélectionnant cet objet dans la liste. Si des éléments d’inventaire ont comme utilisateur le demandeur, il sera possible de spécifier sur lequel porte la demande (partie Mes matériels).

Source de la demande : ce champ permet de préciser l’origine de la demande. La liste des sources est gérée dans le menu Configuration – Intitulés, section Assistance, table Source de la demande. Une source par défaut est désignée pour les tickets issus de l’interface de GLPI et une autre pour les demandes récupérées au travers d’un collecteur mail.

Catégorie : ce champ permet de définir la catégorie de la demande. Les catégories sont gérées dans le menu Configuration – Intitulés, sectionAssistance. Les catégories sont gérées par entité (ne pas oublier de se positionner sur l’entité souhaitée avant de créer les catégories), et de manière arborescente. Il est possible de rendre obligatoire la désignation d’une catégorie pour chaque ticket. Cette information peut être une source très utile pour mettre en place des traitements automatisés à l’aide de règles.

Demande de validation : GLPI offre désormais la possibilité de faire valider une demande d’assistance. La personne en charge de valider le ticket doit être désignée parmi les utilisateurs ayant un profil les y autorisant, et ayant ce profil sur l’entité du ticket.

Tickets liés

GLPI propose d’associer les tickets entre eux :

 Cliquez sur le lien Ajouter. GLPI vous propose alors deux possibilités :

Lié à Ticket ID : ce champ est un champ informatif auquel aucun traitement n’est associé. Saisissez l’identifiant du ticket à associer au ticket en cours.

La liaison est réciproque : l’identifiant du ticket courant apparaîtra dans les liaisons du ticket lié.

Duplique Ticket ID : cette fonction permet de lier le ticket courant avec le ticket dont l’id est saisi ici. Lorsqu’une solution est saisie dans l’un des tickets, celle-ci est automatiquement copiée dans la solution de l’autre ticket.

 Validez la création du ticket en cliquant sur le bouton Ajouter.

3. Par un collecteur de mails

GLPI offre une dernière solution pour alimenter la file de tickets : l’utilisation de collecteurs de mails.

Le principe d’un collecteur de mails est d’interroger le contenu d’une boîte aux lettres de messagerie et de convertir chaque message en ticket. Il n’y a donc dans ce cas aucune saisie à effectuer. Le demandeur rédige donc sa demande dans son courrielleur habituel et envoie son message à une adresse définie.

Il est possible de définir autant de collecteurs que vous le souhaitez. Il sera donc possible d’utiliser plusieurs boîtes aux lettres afin d’effectuer un premier tri dans les demandes. Il est dans ce cas possible d’organiser vos boîtes par entités, par catégories de demandes, etc. Ainsi pour une demande concernant les imprimantes : écrire à la boîte dépannage_imprimantes@masociete.com…

Pour configurer un collecteur de mails

Vous devez avoir des droits de configuration, vous utiliserez donc un compte ayant un profil super-admin.

Connectez-vous avec le compte glpi.

 Placez-vous dans le menu Configuration – Collecteurs.

 Cliquez sur le bouton Ajouter.

Renseignez les différents champs :

Nom : ce champ permet de définir le nom du collecteur de mails. Ce nom doit être explicite car il peut être utilisé comme critère dans les règles de traitement des tickets.

Lorsqu’un collecteur de mails au moins est créé, une nouvelle catégorie de règles s’affiche (menu Administration – Règles). Voir ci-dessous pour la définition des règles liées au helpdesk.

Serveur : ce champ permet de spécifier l’adresse du serveur de messagerie utilisé.

Options de connexion : les champs ci-dessous permettent de définir la façon dont GLPI va se connecter au serveur de messagerie.

• IMAP/POP : ce champ permet de définir si la connexion doit récupérer les messages et les supprimer de la boîte aux lettres (mode POP) ou bien si les messages doivent être conservés sur la boîte après avoir été récupérés (mode IMAP).
• SSL : ce champ permet de définir si la connexion est sécurisée par SSL (Secure Sockets Layers).
• TLS/NO-TLS : ce champ permet de définir si la connexion est sécurisée par TLS (Transport Layer Security).
• NO-VALIDATE-CERT/VALIDATE-CERT : ce champ permet de définir si une vérification de la validité du certificat est nécessaire pour la connexion au serveur de messagerie.

Dossier des messages (optionnel, souvent INBOX) : ce champ définit le dossier dans lequel les messages doivent être récupérés.

Port (optionnel) : ce port dépend du mode de fonctionnement de la connexion (POP ou IMAP) et de la sécurisation ou non de cette connexion. Cela donne : IMAP (port 143), IMAPS (port 993), POP (port 110) et POPS (port 995).

Chaîne de connexion : la chaîne de connexion est un champ calculé à partir des valeurs des champs précédents.

Identifiant : ce champ est l’identifiant du compte ayant les droits en lecture sur la boîte aux lettres.

Mot de passe : ce champ permet la saisie du mot de passe associé au compte ci-dessus.

Taille maximale des fichiers importés par le collecteur : ce champ permet de limiter la taille des pièces jointes aux messages récupérés dans la boîte aux lettres par le collecteur de mails.

Commentaires : ce champ commentaire peut être utile pour expliciter l’utilisation initiale de ce collecteur.

 Validez la création en cliquant sur le bouton Ajouter.

4. Avantages et inconvénients des trois modes d’alimentation

Afin de comparer les différentes solutions, il convient de lister des critères de comparaison :

• La simplicité d’utilisation pour le demandeur.
• La simplicité d’exploitation par les équipes d’assistance.
• La facilité de mise en œuvre et d’exploitation.

La simplicité d’utilisation pour le demandeur

Au travers de ce critère, il faut également lire le niveau d’acceptation du changement dans les habitudes et les contraintes nouvelles imposées.

• Deux modes d’alimentation ressortent ici favoris : l’alimentation par collecteur mails et la saisie par un technicien suite à un appel téléphonique. Ces deux modes ne présentent que peu de difficultés pour le demandeur. Un léger effort de formulation de la demande devra tout de même être fait dans la demande par messagerie, mais cela reste souvent un outil maîtrisé.
• A contrario, le recours au formulaire de saisie en mode authentifié apporte de nombreuses contraintes à l’utilisateur :

• Se connecter à l’outil, avec éventuellement la nécessité d’avoir encore un nouveau mot de passe. Le recours à une source d’authentification externe (voire de SSO) est une nécessité absolue dans le plan d’acceptation de la contrainte.
• Formaliser la demande : L’obligation pour l’utilisateur de décrire son problème est souvent assez mal ressentie. De plus, selon la configuration du formulaire de demande, les champs de saisie obligatoires peuvent agacer les demandeurs qui souhaitent au plus vite cliquer sur le boutonEnvoyer message.
• Une dernière contrainte est d’avoir à disposition une connexion vers le serveur GLPI.

La simplicité d’exploitation par les équipes d’assistance

Ce critère est celui qui doit s’imposer car il préfigure une plus grande efficience dans le traitement des demandes.

• L’utilisation de collecteurs de mails présente un niveau de complexité d’exploitation plus élevé que les autres modes d’alimentation : en effet, dans un message il n’existe aucun formalisme, ni aucune obligation pour le demandeur de formuler sa demande sous une forme permettant une automatisation de son exploitation. Ce mode d’alimentation impose donc un travail important de reformulation et beaucoup de temps gaspillé.

Il est tout de même important de signaler que GLPI est capable à la réception d’un message d’associer le ticket généré à l’utilisateur possédant l’adresse mail émettrice du message.

L’alimentation par le formulaire de saisie en mode anonyme peut se rapprocher de ce niveau de complexité d’exploitation.

• L’utilisation du formulaire par le demandeur en mode authentifié est un compromis intéressant car il permet, en fonction des éléments saisis (dont le cadre est connu), d’effectuer un prétraitement, comme par exemple une attribution automatique du ticket en fonction de la catégorie de la demande. Le demandeur peut également lui-même associer sa demande à un élément de son propre inventaire.
• Enfin, la demande saisie par le technicien permet une reformulation directe et une prise en charge immédiate de la demande. Ce type de mode d’alimentation est celui qui génère le moins d’erreurs de prise en charge.

La facilité de mise en œuvre et d’exploitation

Il n’y a quasiment aucune contrainte dans l’utilisation de collecteurs mail et dans celle des formulaires de saisie par l’utilisateur.

En revanche, la mise en place d’un accueil pour la saisie des demandes par un technicien impose une organisation très lourde à mettre en place et ne peut être envisagée que pour les très grosses structures. La disponibilité doit être permanente dans les plages définies.

En conclusion

Avant de mettre en place un ou plusieurs circuits d’alimentation de la file de tickets, vous devrez commencer par mener une réflexion sur les attentes de vos clients et sur les moyens dont vous disposez pour y répondre.

Votre réponse pourra naturellement être un cumul de plusieurs solutions. Vous devrez dans ce cas bien définir à quels cas d’utilisations correspond chacun des circuits.

Votre analyse pourra se baser sur ces trois critères mais pourra également être complétée par des critères basés sur la formation des utilisateurs, les coûts induits par les différentes solutions….

L’intérêt de cette partie est de vous laisser entrevoir les implications et les contraintes que la mise en place de GLPI pourra avoir sur le fonctionnement de votre structure.

Introduction Pour commencer, une courte définition de ce que peut être le helpdesk.

Introduction

Pour commencer, une courte définition de ce que peut être le helpdesk.

Le helpdesk (centre d’assistance en français) couvre avec un même terme plusieurs notions : il peut tout d’abord s’agir de l’organisation en charge de l’assistance aux utilisateurs, mais il peut également s’agir (comme cela nous intéresse ici) de l’outil nécessaire au traitement de ces demandes d’assistance.

La fonction helpdesk de GLPI s’est très largement enrichie depuis les dernières versions. L’implémentation de ITIL V1 dans la version 0.80 et l’implémentation des versions supérieures de ITIL dans les versions suivantes de GLPI font de celui-ci l’un des outils de helpdesk les plus avancés qui existent.

L’association des demandes d’assistance à des éléments d’inventaire continue également de distinguer GLPI des autres outils libres disponibles sur le marché, permettant un suivi des demandes par élément d’inventaire, par demandeur…

Le champ fonctionnel de GLPI dans le domaine du helpdesk permet enfin d’en faire un outil de suivi de tickets dans des domaines autres que ceux de l’informatique : GLPI se prête tout à fait bien à traiter des demandes relatives aux autres activités de support comme les moyens généraux par exemple.

L’approche de ce chapitre se veut progressive pour vous permettre d’avancer pas à pas dans la mise en place de votre solution de helpdesk. Après avoir fait le tour des nombreuses fonctionnalités proposées par GLPI, il vous est fortement conseillé de prendre le temps de définir votre organisation et de définir le rôle de chaque intervenant afin de configurer l’outil conformément à vos aspirations.

Il est indispensable d’avoir à l’esprit que la mise en place d’une solution de helpdesk permet de faire un point sur le fonctionnement de l’assistance informatique, et que c’est souvent là l’occasion de clarifier les circuits et les rôles de chacun. Cette clarification peut également avoir des répercussions au niveau de l’entreprise tout entière, en étant l’occasion d’apporter une formalisation des demandes d’assistance. Au-delà de la mise en place de l’outil, il conviendra donc de prévoir un plan d’accompagnement visant à définir les circuits des demandes, la liste des différents intervenants et leurs rôles. Tout cela doit également s’accompagner d’un plan de communication pour bien expliquer la démarche et prévenir ainsi les demandes « sauvages » qui sont bien souvent une source de désorganisation de l’assistance.

Il est à noter que les nouveautés fonctionnelles apparues depuis la version 0.80 impliquent ce travail d’analyse et de communication, même si vous utilisiez déjà GLPI dans des versions antérieures. Un seul exemple permet d’illustrer cette impérieuse nécessité : ITIL peut impliquer maintenant que les demandes d’assistance ne soient plus clôturées par le technicien en charge de la demande, mais par le demandeur lui-même au vu de la proposition de solution élaborée par le technicien.

La mise en place d’un outil de helpdesk est extrêmement structurante pour le fonctionnement de l’entreprise et ne peut se faire à la légère. Cette mise en place doit être prise en compte au plus haut niveau de la structure et ne peut être le simple fait d’un membre de l’équipe informatique.

Il est extrêmement fréquent de trouver sur les forums des questions d’étudiants rapportant avoir eu pour mission de mettre en place une solution d’inventaire de parc informatique et d’un outil de suivi des demandes d’assistance au cours d’un stage d’été. Quelle peut être la légitimité d’un stagiaire, par définition extérieur à la structure, pour imposer des procédures nouvelles pour l’équipe informatique, mais également pour toute l’entreprise ?

HD10K Upgrade

Avances please de

estatus de la migracion

ventajas de la nueva version

plan de capacitacion de la gente

responsables del mantenimiento

Hay un sitio web Hyper completo sobre el tema

Es necesario que Omar y una persona del HD se vuelvan expertos en HD10K y lo mismo en NOC

Capaces de Mantener-Optimizar y Capacitar