NON URGENTE TEMPORAIRE DEFINITIVE

Transcription

1 COMMUNICATION TECHNIQUE N TC0778 Ed. 06 Nb de pages : 24 Date : URGENTE NON URGENTE TEMPORAIRE DEFINITIVE OBJET : MIGRATION OmniPCX 4400 VERS Jusqu'en Release 6.2, ce document correspondait à l'annexe 3 de la procédure de mise en service d'une version. A partir de la Release 7.0, cette annexe devient une communication technique à part entière afin de faciliter sa recherche, sa consultation et sa mise à jour. Historique Edition 03 : Mise à jour pour Release 7.1. Edition 04 : Mise à jour pour Release 8.0. Edition 05 : Mise à jour pour Release 9.0. Edition 05 : Mise à jour pour Release

2 2

3 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise MIGRATION OmniPCX 4400 VERS SOMMAIRE 1. PROCÉDURE DE MIGRATION D'UN OMNIPCX 4400 VERS UN OMNIPCX ENTERPRISE R Introduction But de la procédure Contenu de la procédure RÉFÉRENCES RÈGLES GÉNÉRALES DE MIGRATION D'UN SYSTÈME EN R Actis et la migration Synchronisation des opérations à effectuer lors du déploiement de la migration Moyens nécessaires pour la mise en œuvre de la migration Les possibilités de retour arrière Règles à observer CONFIGURATION ACTIS Remplacement des applications et hardware commun aux deux scénarios de migration LIOe / TSC-LIOe INT1/INT LIOB/LIOP/LIOX DECT2/DECT OmniMessage...10 Ed. 06 / TC0778

4 MIGRATION OmniPCX 4400 VERS OmniVista OmniTouch Contact Center Migration ecc "4980 Web Softphone" vers OmniTouch 8400 ICS R Migration 4635 Visual Messenger vers OmniTouch 8400 ICS Equipements de postes 2600, 4600, Equipements de postes Remplacement des applications et hardware spécifiques à chaque scénario de migration Scénario 1 : Migration de type "ISO" Scénario 2 : Migration de type "Appliance Server" Non remplacement des applications et hardware par Actis Cas communs aux 2 scénarios Cas spécifique au scénario 2 : Migration de type "Appliance Server" OPÉRATIONS À RÉALISER SUR LE SITE AVANT DE COMMENCER LA MIGRATION OPÉRATION À RÉALISER EN LABORATOIRE AVANT DE COMMENCER LA MIGRATION Suppression préalable des applications et hardware "phase out" Remplacement des applications et hardware spécifique à chaque scenario de migration Scénario 1: Migration de type "ISO" Scénario 2: Migration de type "Appliance Server" Remplacement des applications et hardware communs aux deux scenarios de migration OmniMessage OmniTouch Contact Center Equipements de postes 2600, 4600, Equipements de postes 4300 S/M/L Déplacement des alvéoles 18 et Préparation des applications et hardwares Moyens nécessaires Gestion complémentaire spécifique à chaque scénario de migration...17 TC Ed. 06 /

5 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise 7. ORGANIGRAMME RÉCAPITULATIF INTEROPÉRABILITÉ EN RÉSEAU HÉTÉROGÈNE BASCULEMENT DE L'INSTALLATION EN R9.1 SUR LE SITE Messagerie vocale en réseau Synchronisation du système Ed. 06 / TC0778

6 MIGRATION OmniPCX 4400 VERS TC Ed. 06 /

7 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise 1. PROCÉDURE DE MIGRATION D'UN OmniPCX 4400 VERS UN R Introduction Ce document s'applique pour la migration d'un OmniPCX 4400 vers un dont la release est égale à But de la procédure Le but de ce document est de conseiller les techniciens à préparer et à mettre en service la migration d'un OmniPCX 4400 Stand-Alone ou réseau vers un R9.1. Cette opération peut être délicate, car elle demande préparation et méthode. En effet, la R9.1 ne supporte pas la migration d'un certain nombre d'applications internes, externes et hardwares "phase out" qui étaient autorisés dans les releases antérieures. Dans une configuration en réseau, des règles d'interopérabilité sont également à respecter entre la R9.1 et des releases hétérogènes. Il faut procéder au remplacement et à la mise à jour de tous ces éléments pour la date de basculement de l'installation en R9.1. Ce document ne traite pas d'adjonctions simultanées de nouvelles fonctionnalités et hardware, excepté lorsqu'il s'agit d'applications et hardwares "phase out". Cumuler les opérations de migration et d'adjonction est fortement déconseillé Contenu de la procédure La procédure décrit les différentes étapes nécessaires à la migration d'une installation en tenant compte de deux scénarios : Scénario 1: Migration de type "ISO" Migration d'un système ayant besoin de nouvelles fonctionnalités de la R9.1 sans modification du type du "Communication Server" c'est-à-dire qu'il conserve ses CPU C'est une migration de type "ISO". Scénario 2: Migration de type "Appliance Server" Migration d'un système ayant besoin de nouvelles fonctionnalités de la R9.1 et de faire évoluer le type du "Communication Server" d'un CPU 4400 par un "Appliance Server" dont les capacités de traitement permettent de diminuer le nombre de nœuds dans le futur, et de les remplacer par des ACT sur IP. C'est une migration de type "Appliance Server". La procédure regroupe les différentes étapes communes aux deux scénarios et distingue les étapes spécifiques à chacun d'entre d'eux. Ed. 06 / TC0778

8 MIGRATION OmniPCX 4400 VERS Chronologies des étapes 1 Règles générales pour la migration d'un système en R Configuration Actis : Remplacement des applications et hardware communs aux deux scénarios. Remplacement des applications et hardware spécifiques à chaque scénario. Non remplacement des applications et hardware par Actis. 3 Opérations à réaliser sur le site avant de commencer la migration. 4 Opérations à réaliser en laboratoire avant de commencer la migration : Opérations communes aux deux scénarios. Opérations spécifiques à chaque scénario. 5 Organigramme récapitulatif. 6 Interopérabilité en réseau hétérogène. 7 Basculement de l'installation en R9.1 sur le site. 2. RÉFÉRENCES Ce document fait référence aux communications techniques suivantes que le technicien réalisant la migration doit avoir : TC0155 Compatibilité Alcatel 4635 et fonds de paniers OmniPCX 4400 (Rappel des restrictions) TC0259 Procédures de migration TC0487 Migration ACD-V1 vers CCDistribution TC0779 Synchronisation du système après migration vers avec Appliance Server TC1253 Alcatel Procédure de mise en service de la version Release 5 TC1292 Procédure de mise en service de la version I e - Release RÈGLES GÉNÉRALES DE MIGRATION D'UN SYSTÈME EN R Actis et la migration Tout système migrant en R9.1 doit être configuré par Actis 14.1 catalogue E12 (Actis 14.2 et catalogue E13 en cas d adjonction avec des cartes NGP). Comme Actis connaît les applications externes et internes, le hardware "phase out" non reconduits dans cette release, il prend en charge la commande de ces applications et hardware. Cependant, dans certains cas, il sera nécessaire de prévoir des opérations non prises en compte par Actis. TC Ed. 06 /

9 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise 3.2. Synchronisation des opérations à effectuer lors du déploiement de la migration Le déploiement de la migration nécessite une synchronisation parfaite des opérations à réaliser par les techniciens, avant, pendant et après la migration Moyens nécessaires pour la mise en œuvre de la migration La préparation de la migration sur un système de laboratoire permettra dans bien des cas de faciliter le travail, de diminuer le temps de présence sur le site et de minimiser les perturbations du système Les possibilités de retour arrière A chaque étape du déploiement de la migration, il faut prévoir la possibilité de retour en arrière en cas de problème grave en cours de migration Règles à observer Du fait de l'obsolescence d'applications et hardwares, la préparation d'une migration doit observer un certain nombre de règles afin de limiter le temps d'indisponibilité du système pour le client. Actis migre le système en R9.1 en une seule étape c'est-à-dire qu'il considère que l'ensemble des applications et hardwares "non migrables" a été remplacé. Cependant, la planification de la migration doit s'efforcer de limiter le cumul des opérations à effectuer au dernier moment. Dans le cas de migration de systèmes en réseau, une étude préalable par le service Pré-Sales doit être réalisée afin de révéler si besoin est, des cas d'incompatibilité entre les différents hardwares utilisés pour la voix sur IP. Ces informations doivent être retransmises au technicien en charge de la réalisation de la migration. 4. CONFIGURATION ACTIS A l'issue de la configuration, Actis prévoit le remplacement des applications et hardware "phase out" ainsi que le remplacement des applications et hardware en fonction du type de scénario de migration. Actis génère des licences et du matériel dont une partie peut être utilisée immédiatement en laboratoire par le technicien. Dans tous les cas, il sera nécessaire de planifier méthodiquement les opérations à effectuer. Le remplacement des applications et hardware commun aux deux scénarios de migration est décrit au 4.1. Le remplacement des applications et hardware spécifique à chaque scénario de migration est décrit au Le non remplacement des applications et hardware commun aux deux scénarios de migration est décrit au 4.3. Ed. 06 / TC0778

10 MIGRATION OmniPCX 4400 VERS 4.1. Remplacement des applications et hardware commun aux deux scénarios de migration La R9.1 ne prenant plus en compte certaines applications et hardware "phase out", Actis prévoit leur remplacement pour les deux types de scénarios de migration LIOe / TSC-LIOe Les cartes LIOe et TSC-LIOe ne sont plus supportées à partir de la Release 6.0. Lors de la migration, elles sont automatiquement remplacées par des cartes INTIP2. Des lots de migration INTIP2 ont été créés pour favoriser le remplacement et baisser le coût. Note Les cartes LIOe et TSC-LIOe doivent également être remplacées dans le cas d un fonctionnement en réseau hétérogène quelque soit la version des nœuds en face d'une R INT1/INT2 Ces cartes ne sont plus supportées à partir de la Release 6.1. Pour les installations équipées de ces cartes, Actis remplace automatiquement les cartes : INT1A / INT2A par des cartes INTOF2 A, INT1B / INT2B par des cartes INTOF2 B LIOB/LIOP/LIOX Ces cartes sont en "phase out" à partir de la Release 6.1. Depuis Actis 10.1, cette fonctionnalité est interdite en adjonction ou sur une nouvelle installation DECT2/DECT4 Les cartes DECT2/DECT4 configurées dans des affaires à migrer, sont encore supportées sur Release 5.1, 6.0.x, 6.1.x, 6.2, 7.x, 8.0.x, 9.x mais interdites en adjonction. De plus, les cartes DECT8 ne sont pas compatibles avec les DECT2/DECT4. Il faut remplacer ces dernières par des cartes DECT OmniMessage La messagerie vocale Alcatel 4630 est remplacée par la messagerie vocale Alcatel 4635J. Les messageries vocales Alcatel 4635H et 4635H-1 sont remplacées par des messageries vocales Alcatel 4635H-2. TC Ed. 06 /

11 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise Etat matériel 46xx du système à migrer : Etat avant migration VPCPU VPCPU-1 VPM35 VPS35 MSB MSB2IB MSB2IB VMU-OBCA (carte CPU3) VMU-OBCA (carte CPU5) Etat après migration VPM35-1 VPM35-1 VPM35-1 VPU6 MSBI ATB2 (si une carte MSBI) ATB3I (si deux cartes MSBI) VMU-OBCA2 (avec carte CPU6) IO2N (avec carte CPU7) OmniVista Les applications 4715, 4730, 4740, 4755, 4760 R1.0, 4760 R1.5 sont remplacées par l'application OmniVista 4760 Release Les sites équipés d'une OmniVista 4760 R2.x, R3.x, R4.0, R4.1, R4.2, R5.0 doivent migrer en Release Pour plus d'informations sur la compatibilité des releases OmniVista 4760/, se reporter à la communication technique TC1292 Procédure d'installation de la version I e Release OmniTouch Contact Center L'ACDV1 est remplacé par le CCD. Les superviseurs sont remplacés par le CCS Migration ecc "4980 Web Softphone" vers OmniTouch 8400 ICS R6.1 L application ecc "4980 Web Softphone" est automatiquement migrée vers l application OmniTouch 8400 ICS R Migration 4635 Visual Messenger vers OmniTouch 8400 ICS L application 4635 Visual Messenger n est plus supportée en Release 9.1. Elle est remplacée par l application OmniTouch 8400 ICS R Equipements de postes 2600, 4600, 5400 Les équipements analogiques 2600, 4600 et 5400 sont remplacés par des cartes ez32. Les équipements numériques 2600, 4600 et 5400 sont remplacés par des cartes eua Equipements de postes 4300 Les équipements analogiques 4300 (ELA) sont remplacés par des cartes ez32. Les équipements numériques 4300 (ELN) sont remplacés par des cartes eua32. Ed. 06 / TC0778

12 MIGRATION OmniPCX 4400 VERS 4.2. Remplacement des applications et hardware spécifiques à chaque scénario de migration La R9.1 ne prenant plus en compte certaines applications et hardware "phase out", Actis prévoit en plus leur remplacement en fonction du type de scénario de migration Scénario 1 : Migration de type "ISO" Ce type de migration est destiné à offrir de nouvelles fonctionnalités au client. Le "Call Server" reste du type CPU 4400, mais la R9.1 ne prenant plus en compte certaines applications et hardwares "phase out", il sera nécessaire de planifier méthodiquement les opérations à effectuer Communication Servers Migration vers R9.1 avec changement de CPU. Les systèmes configurés avec CPU3 passent en CPU6 avec : remplacement automatique du disque dur si inférieur à 10 Go, mémoire SDRAM de 128 Mo. Les systèmes configurés avec CPU5 Step1/CPU5 Step2/CPU5 Step3 passent en CPU7 avec : remplacement automatique du disque dur si inférieur à 10 Go, mémoire SDRAM de 256 Mo. Les systèmes configurés avec CPU6 restent en CPU6 : avec remplacement automatique du disque dur, si inférieur à 10 Go, mémoire SDRAM de 128 Mo IO2 La carte IO2N est configurée à la place de la carte IO2 si, lors de la migration, Actis configure une carte CPU7.x OBCA Contrairement à la carte CPU6, la carte CPU7.x ne supporte pas la carte fille OBCA2. Actis configurera la carte IO2N lorsque le nombre de canaux B calculés sera différent de zéro. TC Ed. 06 /

13 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise Scénario 2 : Migration de type "Appliance Server" Ce type de migration remplace une CPU 4400 par un Appliance Server et une INTIP2 et implique la suppression des coupleurs IO2, IO2N et OBCA. Comme pour la migration type ISO, la Release 9.1 ne prend plus en compte certaines applications externes, applications internes et hardware "phase out". Ces restrictions sont plus importantes du fait de la disparition du coupleur IO2, IO2N ou OBCA Communication Servers Les CPU 4400 sont supprimées et remplacées par des Appliance Servers. Les IO2 sont supprimées et remplacées par des INTIP RMA Le RMA est supprimé et remplacé par un RMA dans un coffret de type S (rack 1U) Cas particulier où l'appliance Server remplace une CPU6 Ajout d'une carte GPA2 pour les guides vocaux et les générateurs Q23, si ceux-ci étaient fournis par les CPU6. La messagerie vocale 4615 sur carte fille VMU/OBCA est remplacée par une messagerie vocale 4635J. La carte fille DTM pour la synchronisation de DECT est supprimée et remplacée par une carte DECT8 pour assurer la même fonction. Si le site était équipé de cartes DECT2 ou DECT4, ces dernières n'étant pas compatibles avec des DECT8, elles seront remplacées par des cartes DECT Non remplacement des applications et hardware par Actis Cas communs aux 2 scénarios Quelque soit le type de migration, Actis ne prévoit pas le remplacement des cartes filles SPB (extension des ports V24 du système), mais il force la suppression de ce circuit. L'opérateur Actis a alors le choix de remplacer les anciens accès sur SPB, soit par des accès TA V120 soit par un ou plusieurs boîtiers V24-IP Cas spécifique au scénario 2 : Migration de type "Appliance Server". Dans les cas liés à la suppression d'io2, IO2N, OBCA, Actis ne configure pas le hardware qui pourrait être impliqué dans le remplacement des fonctionnalités utilisant ces cartes. Les ACT de niveau 3 raccordés derrière un coupleur INTOF, ne sont plus autorisés. Ils doivent être remplacés par des ACT-IP. Actis n'ayant pas connaissance des ACT de niveau 3 installés sur le site, ne prend pas en compte le remplacement des coupleurs INTOF par des coupleurs INTIP. Ces opérations doivent être réalisées manuellement en utilisant Actis. Ed. 06 / TC0778

14 MIGRATION OmniPCX 4400 VERS 5. OPÉRATIONS À RÉALISER SUR LE SITE AVANT DE COMMENCER LA MIGRATION Remplacer la carte SPB par des accès V120 sur IO2 ou IO2N ainsi que les messageries vocales 4635H et 4635H-1. Le remplacement peut être effectué sur le site avant la migration car elles ne nécessitent pas de nouvelles licences. Sauvegarder la base de données et les données Chorus sur le site ( Note). Cette base de données sert à la préparation de la migration en laboratoire. Cela signifie qu'à partir du moment où cette base de données est sauvegardée, jusqu'au basculement du site en R9.1, toutes les modifications apportées sur le site ne seront pas reconduites, sauf si elles ont été répertoriées par le client. Note Il n y a pas de translation automatique des données Chorus des Releases inférieures à R3.0. Vous ne devez pas restaurer les données Chorus des Releases inférieures à R3.0 mais refaire manuellement un netadmin complet. 6. OPÉRATION À RÉALISER EN LABORATOIRE AVANT DE COMMENCER LA MIGRATION La préparation de la migration en laboratoire présente l'avantage de limiter les temps d'intervention et les perturbations de fonctionnement sur le site. ATTENTION Il n'est pas possible de migrer une base de données d'une Release inférieure à R1.5 vers la R9.1. En conséquence, tout site dont la Release de départ est inférieure à R1.5, doit obligatoirement passer par une translation intermédiaire de la base de données, sur une Release comprise entre R1.5 et R5.0.1 Ux Suppression préalable des applications et hardware "phase out" Les applications et hardware "phase out" ne peuvent pas être supprimés sur la base de données en R9.1. Il est donc nécessaire de les supprimer sur la version actuelle du site. Cette opération doit être réalisée sur maquette en laboratoire. Moyens nécessaires Une sauvegarde de la base de données du site à migrer. Un ACT Une CPU installée avec une version équivalente ou supérieure à celle du site sur laquelle les applications et hardware "phase out" seront supprimés. TC Ed. 06 /

15 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise 6.2. Remplacement des applications et hardware spécifique à chaque scenario de migration Scénario 1: Migration de type "ISO" Communication Servers Modifier le type de CPU si celui-ci a changé. RAPPEL Il est impératif de gérer le bon type de CPU sinon un problème d'initialisation des coupleurs DECT ou INTOF peut apparaître (par exemple, dans le cas d'un changement de CPU3 en CPU6) Carte fille SPB La suppression et le remplacement de la carte SPB par des accès V120 ont pu être réalisés sur le site avant la migration, et avant la sauvegarde de la base de données. Dans le cas de remplacement de SPB par une V24-IP, les essais peuvent être réalisés en laboratoire Scénario 2: Migration de type "Appliance Server" Communication Servers Aucune modification n'est nécessaire, car la translation de la base de données supprime les CPU et IO Carte fille SPB Noter et supprimer les applications data raccordées sur SPB et IO2 car les cartes SPB et les IO2 sont supprimées lors des translations. Ces applications seront créées ultérieurement sur V24-IP. Suppression d'io2, IO2N, OBCA. Les fonctionnalités non migrées suite à la suppression des IO2, IO2N, OBCA, telles qu'artères sur canal B, artères via modem, secours de signalisation via ISDN, X25 sur canal B, doivent être supprimées si cela n'a pas déjà été fait sur le site avant de commencer la procédure de migration, c'est-à-dire avant la sauvegarde de la base de données. Remplacement d'une CPU6 par un Appliance Server. Supprimer les guides vocaux et musique de garde sur la CPU6. Supprimer les boîtes vocales 4615 des usagers, puis supprimer la messagerie vocale Ed. 06 / TC0778

16 MIGRATION OmniPCX 4400 VERS 6.3. Remplacement des applications et hardware communs aux deux scenarios de migration OmniMessage Suppression de la messagerie vocale Supprimer les boîtes vocales 4630 aux usagers puis supprimer la messagerie Migration des messageries vocales 4635H et 4635H-1 vers 4635H-2. Il n'y a pas de suppression liée à cette opération OmniTouch Contact Center La migration de l'acdv1 doit être préparée en laboratoire. La suppression des objets ACDV1 est obligatoire avant d'effectuer les translations de la base de données, car il ne sera plus possible de les supprimer en R9.1. Se reporter à la communication technique TC0487 Migration ACD-V1 vers CCDistribution Equipements de postes 2600, 4600, 5400 La migration des racks et des cartes doit être préparée en laboratoire, car leur suppression n'est pas possible en R9.0. Désaffecter les usagers et supprimer les racks et les circuits non migrés avant d'effectuer les translations Equipements de postes 4300 S/M/L La migration des racks et des cartes doit être préparée en laboratoire. Les usagers seront conservés après la translation en R9.0 mais sans équipement ( ) Déplacement des alvéoles 18 et 19 Les alvéoles déjà créées en position 18 et 19 doivent être déplacées avant d'effectuer la translation. Si ce n'est pas fait, elles ne redémarreront pas. En effet, il n'existe pas de translation automatique des alvéoles créées dans ces 2 positions contrairement à la migration avec Appliance Server. Le changement peut être effectué sur site avant migration. Attention dans le cas d'alvéole déportée sur IP (Remote IP), ne pas oublier de renuméroter les cartes INTIPB (à l'aide des cavaliers sur la carte). TC Ed. 06 /

17 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise 6.5. Préparation des applications et hardwares Moyens nécessaires Une sauvegarde de la base de données sur laquelle ont été supprimés les applications et hardware "phase out". Un ACT Scénario 1 : Migration de type "ISO". Un disque dur 10 Go minimum si la/les CPU du site n'ont pas besoin d'être changées au titre de la migration ou une CPU6 Step2/CPU7 si celle-ci est destinée à remplacer la CPU du site. Scénario 2 : Migration de type "Appliance Server". Les Appliances Servers et les INTIP2 du client. Les fichiers OPS R9.1 générés par Actis. Ces fichiers sont au nombre de 4 ou 5 : <offre_id>.zip <offre_id>.swk <offre_id>.hw hardware.mao <offre_id>.sw4760 (si présence 4760 sur le site) Le matériel généré par Actis peut être préparé en laboratoire Gestion complémentaire spécifique à chaque scénario de migration Scénario 1: Migration de type "ISO" Lorsque les CPU du site ne sont plus conformes, Actis passe commande d'une CPU6 ou CPU7 à l'industriel. Ces CPU peuvent être utilisées pour la préparation de la migration. Les CPU venant d'usine ont toutes un CPU_ID flashé d'origine. Si les CPU du site sont conformes, alors les clés hard peuvent être conservées. Dans ce cas, la préparation de la migration doit être effectuée sur une CPU de laboratoire équivalente à celle du site, et dont le disque sera implanté ultérieurement sur la CPU du client Communication Servers Installer le logiciel R9.1 sur la CPU (1). Charger la base de données du site (1). Charger les données Chorus du site (1 & 2). Ne pas démarrer le téléphone (1). Installer les fichiers OPS (1). La procédure d'installation des fichiers OPS a changé à partir de la R5.0 Lx par rapport aux releases précédentes. Elle enchaîne les étapes suivantes: RUNMAO, translation de la base de données et installation des fichiers OPS. Ed. 06 / TC0778

18 MIGRATION OmniPCX 4400 VERS (1) Suivre la communication technique TC1292 Procédure d'installation de la version I e Release 9.1. (2) Ne pas restaurer les données Chorus si vous venez d une Release inférieure à R LIOe Les cartes LIOe et TSC-LIOe ne sont plus supportées ; se reporter au paragraphe La gestion de ces cartes doit être supprimée et être remplacée par une gestion de cartes INTIP. Configurer les adresses MAC des INTIP par la gestion INT1/INT2 Les cartes INT1/INT2 ne sont plus supportées ; se reporter au paragraphe La gestion de ces cartes doit être supprimée et être remplacée par une gestion de cartes INTOF OmniMessage Remplacement de la messagerie vocale 4630 par une messagerie 4635J. La préparation de la messagerie 4635J peut être effectuée en laboratoire, dès réception du matériel, mais la migration des annonces et des messages n'étant pas possible entre les deux produits, il faut prévoir en accord avec le client, le gel du service vocal sur le site avant la migration en R9.1, afin de ne plus autoriser de dépôts de messages. Il s'agit d'un remplacement et non d'une migration. Migration de la messagerie vocale 4635H et 4635H-1 vers la messagerie 4635H-2. Cette migration ne nécessite pas de nouveaux verrous. Elle peut être réalisée sur le site avant la migration en R9.1. Cela dépend de la compatibilité des VPM35 avec la version du site. S'il y a compatibilité, le fait de réaliser cette opération avant la migration, évitera le cumul des opérations, le jour du basculement en R9.1. S'il n'y a pas compatibilité entre la VPM35 et la version du site, une partie de la migration peut être effectuée en laboratoire dès réception de la carte VPM35. Le transfert des annonces et des messages est possible en laboratoire, dans la mesure où le client accepte le gel du service vocal pendant un période à définir. Si l'interruption de service n'est pas possible, le transfert des annonces et des messages doit être effectué lors de la migration sur le site. Se reporter aux communications techniques : TC0155 Compatibilité Alcatel 4635 et fonds de paniers OmniPCX 4400 (Rappel des restrictions) TC0259 Procédures de migration TC1253 Alcatel Procédure de mise en service de la version Release OmniVista Migration des applications 4715, 4730, 4740 et 4755 vers l'application OmniVista 4760 Release Cette migration est réalisable sur le site, dès réception du matériel, à condition qu'elle soit faite dans les 21 jours précédant le basculement en R9.1. Ceci est conseillé pour éviter le cumul des opérations, le jour du basculement en R9.1. TC Ed. 06 /

19 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise Pour plus d'informations sur la compatibilité des releases OmniVista 4760/, se reporter à la communication technique TC1292 Procédure d'installation de la version I e Release OmniTouch Contact Center Les groupes ACDV1 migrent en CCD. Les superviseurs migrent en CCS. Se reporter à la communication technique TC0487 Migration ACD-V1 vers CCDistribution Equipements de postes 2600, 4600, 5400 Les équipements analogiques 2600, 4600 et 5400 migrent en ez32. Les équipements numériques 2600, 4600 et 5400 migrent en eua32. Créer les ACT 4400 et les circuits ez32 et eua32. Affecter les usagers analogiques et numériques. Dès réception du matériel, il est possible de commencer son installation sur le site Equipements de postes 4300 S/M/L Les équipements analogiques 4300 (ELA) migrent en ez32. Les équipements numériques 4300 (ELN) migrent en eua32. Créer les ACT 4400 et les circuits ez32 et eua32. Affecter les usagers analogiques et numériques dont l'équipement a été supprimé par la translation en R9.1. Dès réception du matériel, il est possible de commencer son installation sur le site Carte fille SPB Le technicien doit s'assurer de la présence du matériel de remplacement. Les ports V24 sur SPB sont remplacés par des accès TA V120 via IO2 ou par des accès via boîtiers V24-IP. Créer les accès V120 pour les applications précédemment connectées sur SPB. Dans le cas de remplacement de SPB par une V24-IP, les essais peuvent être réalisés en laboratoire. Note La suppression et le remplacement de la carte SPB par des accès V120 peuvent être réalisés sur le site avant la migration, et avant la sauvegarde de la base de données. Ed. 06 / TC0778

20 MIGRATION OmniPCX 4400 VERS Scénario 2 : Migration de type "Appliance Server" Communication Servers Installer le logiciel R9.1 sur l'appliance Server (1). Charger la base de données du site (1). Charger les données Chorus du site (1 & 2). Ne pas démarrer le téléphone (1). Installer les fichiers OPS (1). La procédure d'installation des fichiers OPS a changé à partir de la R5.0 Lx par rapport aux releases précédentes. Elle enchaîne les étapes suivantes: RUNMAO, translation de la base de données et installation des fichiers OPS. (1) Suivre la communication technique TC1292 Procédure d'installation de la version I e Release 9.1. (2) Ne pas restaurer les données Chorus si vous venez d une Release inférieure à R Remplacement de la CPU6 par un Appliance-Server Créer le coupleur GPA2. Créer les guides vocaux sur GPA2. Créer la musique de garde sur un équipement Z. Créer une messagerie vocale 4635 et affecter les boîtes vocales aux usagers. Créer le coupleur DECT8. ATTENTION Si le site comporte des coupleurs DECT2 ou DECT4, ils sont incompatibles avec le coupleur DECT8 et doivent être remplacés par des coupleurs DECT Suppression d'io2, IO2N, OBCA Le remplacement des fonctionnalités non migrées suite à la suppression des IO2, IO2N, OBCA, telles qu'artères sur canal B, artères via modem, secours de signalisation via ISDN, X25 sur canal B, a déjà été réalisé sur le site avant de commencer la procédure de migration, c'est-à-dire avant la sauvegarde de la base de données ACT de niveau 3 Supprimer les coupleurs reliant les ACT de niveau 3, aux ACT de niveau 2, et les remplacer par des coupleurs INTIPB équipés de cartes compresseurs. ATTENTION Des compresseurs sont nécessaires en central pour assurer les liaisons audios avec cet ACT-IP. Ils sont prévus par Actis. TC Ed. 06 /

21 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise Modifications liées à la mise en place des Appliances Servers Il est conseillé de tester en laboratoire les ensembles Appliances Servers et INTIPB. Mode opératoire Créer les coupleurs INTIP2 en mode INTIPB ou IOIP en position 6, 20, (ou 10) de l'ancienne ACT0 devenue ACTx, (vérifier dans le dossier Actis le mode à configurer). Note Les CPU et IO2 ont été supprimés lors de la translation. Les INTIPB et IOIP se configurent toutes les deux sur un coupleur INTIP2. Configurer les adresses MAC des INTIP2 par la gestion. Configurer l'actx (ancienne ACT0) en Media Gateway de référence. Configurer les switchs donnant la position de l'actx sur les coupleurs INTIP2. Configurer les données IP des coupleurs INTIP2 (mode d'adressage statique), à l'aide d'un terminal VT100. ATTENTION Le câble de raccordement du terminal sur les coupleurs INTIP2 est différent du câble des INTIP. Il est identique à celui des cartes GD soit 3EH AAAA. Note En mode IOIP, les coupleurs INTIP2 ne peuvent pas supporter de carte compresseur. 7. ORGANIGRAMME RÉCAPITULATIF Ed. 06 / TC0778

22 MIGRATION OmniPCX 4400 VERS Migration OmniPCX 4400 vers Release 9.1 Avant de commencer, faire le point des :. applications et matériels à changer( 4 Procédure de mise en service de la Release 9.1). compatibilités d'installation en réseau ( 6 Procédure de mise en service de la Release 9.1). compatibilités ( 7 Procédure de mise en service de la Release 9.1) oui Pouvez vous faire évoluer des fonctionnalités supprimées en R9.1 dans la version actuelle? non Faire une sauvegarde de la base de données courante. Cette sauvegarde n 1 sera votre référence (saveref1) en cas de retour en arrière Remplacer tout ce qui est possible dans votre version actuelle (sans rajouter de nouvelles licences) - 47x x --> 4760 (TCV036 Fonctionnement possible 21 jours sans licence officielle) > 4635 H2 (TC0155, TC0259 et TC1253) - LIOE/TSCLIOE --> INTIP - OBCA - -> IO2N dans le cadre de la CPU7 - IO2 - -> IO2N dans le cadre de la CPU7 - INT1/INT2 --> INTOF/INTOF2 - Scénario 1 : SPB --> IO2, supprimer les ports utilisés et les recréer sur IO2 - Scénario 2 : Supprimer les cartes IO2, IO2N et OBCA Avertir le client des contraintes imposées par le changement de version :. Gel de la gestion (pendant une période définie avec le client). Risque de perdre, suivant votre évolution, les messages, les annonces dans le cas d'un changement de messagerie vocale (TC TC TC0298 -TC1253). Remplacement de l'acdv1 par CCD (TC0487) à la mise en service de la Release 9.1 oui Avez vous d'autres fonctionnalités à remplacer? non La version du site est < R1.5.3 non Faire une sauvegarde de la base de données courante. Cette sauvegarde n 2 sera votre référence (saveref2) en cas de retour en arrière Les opérations suivantes doivent être effectuées uniquement en laboratoire oui Translater les données dans une Release compatible avec la R9.1 (R1.5.3 à R5.0.1Ux) Aller en B Aller en A TC Ed. 06 /

23 MIGRATION OmniPCX 4400 VERS OmniPCX Enterprise B non La version du site est < R1.5.3 oui Translater les données dans une Release compatible avec la R9.1 (R1.5.3 à R5.0.1Ux) Restaurer votre base de données savref2 sur une CPU chargée avec la même version que le site ou une Release inférieure ou égale à R5.0.1Ux Faire une sauvegarde de la base de données courante ( 9.4). Cette sauvegarde n 3 (saveref3) sera utilisée pour effectuer les translations en R9.1 Gestion à faire : Alvéole 2600/5400 : Désaffecter tous les équipements utilisés et supprimer les cartes&alvéoles 2600/5400. ACDV1 : Supprimer l'acdv : Supprimer la 4630 (voir TC0298) A Faire une sauvegarde de la base de données courante ( 9.4). Cette sauvegarde n 4 (saveref4) sera utilisée pour effectuer les translations en R9.1 Votre gestion est maintenant prête à être translatée en R9.1 Vous devez avoir maintenant les fichiers Actis pour la R9.1 Au préalable il y aura eu une demande de verrous par Actis et vous avez donc maintenant 4 à 5 fichiers (avec 4760 ou pas) Installer la R9.1, si possible, sur une CPU qui sera mise sur site Une fois le système chargé, installer la base de données (saveref4) puis charger les fichiers OPS (via swinst --> 12.1) La translation est effectuée automatiquement après chargement des fichiers OPS Gérer les fonctionnalités manquantes :. Equipements eua32 et ez32 remplaçant les équipements des 2600, 4300 et CCD. Alcatel Scénario 1 : Gérer le bon type de CPU. Scénario 2 : Remplacer les anciens accès sur SPB par des boîtiers V24-IP Remplacer les anciens ACT de niveau 3 derrière INTOF par des ACT derrière INTIP Faire une sauvegarde de la base de données courante ( 9.4). Cette sauvegarde n 5 (saveref5) sera celle avec la nouvelle gestion R9.1 Votre CPU est maintenant chargée en R9.1 avec les nouvelles fonctionnalités. Elle est prête à être mise sur site. FIN Ed. 06 / TC0778

24 MIGRATION OmniPCX 4400 VERS 8. INTEROPÉRABILITÉ EN RÉSEAU HÉTÉROGÈNE Se reporter aux paragraphes 5, 6 et 7 de la communication technique TC1292 Procédure d'installation de la version I e Release BASCULEMENT DE L'INSTALLATION EN R9.1 SUR LE SITE 9.1. Messagerie vocale en réseau Modifier le type de boîte vocale des usagers des autres nœuds si la messagerie vocale centralisée était une Synchronisation du système ATTENTION Un OmniPCX 4400 qui migre en avec Appliance Server est désormais soumis aux règles de synchronisation par domaine. Modifier les priorités de synchronisation des accès numériques. Se reporter à la communication technique TC0779 Synchronisation du système après migration vers avec Appliance Server. Les règles de synchronisation sont expliquées dans la section "Synchronisation des PABX" de la documentation technique. TC Ed. 06 /