Manual always on

7.2.1.1 piloto

Como parte de la prueba piloto, tanto el paquete de software y el servicio shoulderstand ser probados por los usuarios piloto
en el lugar antes de la implantación.

De tareas de SML / IO:

1. Definición de los usuarios piloto
Definir usuarios y periodo de pruebas piloto.

2. Instalación del componente de software en los dispositivos finales
Asegurar hicieron AlwaysOnestá preinstalado en los clientes de los usuarios piloto.

3. Implementación del piloto
Los usuarios activar sus dispositivos finales a través de auto-servicio (http://slbemnet050.destr.corpintra.net/alwayson) y siga las instrucciones para la puesta en marcha inicial hizo luego se ha enviado por e-mail.

4. Los resultados de Información al piloto S4G PMO
Solicitar la opinión de los usuariospiloto después del período de prueba definida se ha completado y reportar sus experiencias al S4G PMO
(S4G-EUD@Daimler.com).

5. Decidir si o no para liberar AlwaysOn

Utilizar los resultados experimentales para decidir si AlwaysOn se puede rodar hacia fuera en su lugar.
Si la decisión es positiva, comenzar con los preparativos se describe a continuación.

7.2.1.2 Preparativos

Si losresultados del proyecto piloto son positivos, los hombros se preparará el despliegue.
De tareas de SML / IO:
1. Garantizar la implantación de software

Software se puso en marcha en el lugar ("Juniper Networks Junos Pulse cliente siempre-en 5.0.3.44471 MUI" paquete, número de artículo: QEV111AF22IS)

2. Adaptación de los servidores de seguridad locales a las nuevas redes de acceso

Espacioslibres existentes para el acceso remoto se amplían para incluir los nuevos rangos de red de acceso AlwaysOn en firewalls locales. En el C4M98V1 especificación, las nuevas gamas de acceso están documentadas en https://team.sp.wp.corpintra.net/sites/00291/cfr.

3. Definir el proceso de retorno simbólico

Las personas jurídicas son los dueños de los tokens emitidos. La vuelta se organizólocalmente. Las fichas son retenidos por la organización y se pueden volver a emitir para otras aplicaciones (por ejemplo, SSL-VPN de socios de negocios).


Con entidades no jurídicas, las fichas son devueltos al Servicio de Informática móvil en el CUHD por correo interno. Las instrucciones de devolución son parte de la notificación de migración para el usuario final. MCS registros devueltos fichas ylos informa de TI solicitantes de un PLC

TI PLC solicitantes de las personas jurídicas y no jurídicas debe documentar rendimiento simbólico en TI PLC (desactivación del servicio "SRA TOKEN VASCO"). Provisión de emergencia para los usuarios se continua con cargo a la entidad A no ser que la desactivación del servicio de TI PLC.



4. La adaptación de las plantillas de comunicación y su envíoa S4G PMO
Adecuar las plantillas de comunicación (Servicio de Migración del usuario E-mail) a los requerimientos locales y enviarlos a la S4G PMO (S4G-EUD@Daimler.com).

Dos plantillas se proporcionan: Una plantilla con instrucciones para el token de retorno y un sin instrucciones. Los usuarios migrados recibirán un e-mail basado en una de las dos plantillas. La decisión depende de que se eligela plantilla si el usuario final es conocido el uso del token para otras aplicaciones.

Las plantillas son archivos HTML. Sólo texto 'puede ser cambiado o traducido. Para las personas jurídicas, las instrucciones de devolución de fichas deben angepasst. Las entidades no jurídicas no cambian las instrucciones.

5. Actualización de la configuración local de TI PLC
A fin de que los solicitanteslocales de TI PLC para solicitar defecto AlwaysOn para los nuevos usuarios, la instalación local de TI PLC necesita ser cambiado. Cambios necesarios están documentados en la guía de implementación de TI PLC.

6. Las decisiones de definición para las fechas de migración
Una vez que el piloto se ha completado con éxito y todos los preparativos de migración de este modo se ha completado, la...