Migrer myContactCenter V10 vers un nouveau serveur

Une migration de serveur reprend une installation myContactCenter existante avec ses agents, compétences, flows, conversations, statistiques et données de licence. Installez les programmes sur l’ordinateur de destination et transférez les bases de données existantes ainsi que les fichiers nécessaires. Une nouvelle installation avec des bases de données vides ne restaure pas ces données.

Prévoyez une fenêtre de maintenance : le centre de contacts est indisponible pendant la sauvegarde finale et la bascule. Terminez les conversations en cours au préalable et informez les agents.

1. Définir le périmètre et le plan de retour

Avant la migration, notez la version installée, les noms des ordinateurs, les instances SQL et les noms des bases de données, les comptes de service, les Dispatchers et les emplacements des fichiers. Déterminez les composants qui seront effectivement déplacés :

Modification	Ce que vous devez adapter
Seul le serveur myContactCenter est déplacé ; les bases de données et les Dispatchers restent en place	L’accès aux bases de données et le compte de service sur le nouvel ordinateur, les noms des serveurs dans le Dispatcher et la configuration du serveur, la connexion directe de l’Administration
SQL Server ou la base de données de supervision sont également déplacés	Les deux bases de données concernées, avec leurs connexions et droits, les paramètres de base de données dans le Server Configurator et l’accès pour les rapports
Le Dispatcher est déplacé ou change de nom	Les points d’enregistrement des agents, wallboards, Loggers et Routing Services
Le Routing Service, le Logger ou les emplacements de fichiers sont déplacés	Leurs paramètres locaux, comptes de service, connexion SIP, chemins et droits ; pour le chat web et WebCallback, également la connexion du site web

Conserver le nom DNS peut éviter des modifications sur les postes de travail. Vérifiez néanmoins qu’il pointe vers le bon ordinateur après la bascule. Le nom du serveur, l’instance SQL et le point d’enregistrement sont des adresses différentes ; modifier l’une ne modifie pas les autres. Voir Noms et adresses.

Pour la migration, installez si possible la même version sur le système de destination. Effectuez une mise à jour supplémentaire comme étape distincte et vérifiez d’abord les versions compatibles. Le Server Configurator et le serveur peuvent mettre à jour le schéma des bases de données au démarrage ; une version antérieure du programme ne constitue alors plus un retour garanti.

2. Sauvegarder les bases de données et les fichiers

Sauvegardez d’abord un état de test pour vérifier à l’avance la restauration sur le système de destination. Pour le transfert définitif :

Fermez les agents et les wallboards. Arrêtez les anciens Routing Services pour ne plus traiter de nouveaux appels, e-mails, chats ou rappels.
Arrêtez l’ancien serveur myContactCenter et les autres services concernés. Dans un ensemble maître/secours, tenez également compte de ses services et de la synchronisation.
Avec les outils de chaque système de base de données, effectuez une sauvegarde complète de la base de données de configuration et de la Base de données de supervision à partir de cet état arrêté.
Sauvegardez les connexions SQL ou les rôles PostgreSQL et les fichiers indiqués ci-dessous. Notez les sauvegardes qui vont ensemble.

La base de données de configuration contient notamment les agents, administrateurs, compétences, flows, statistiques et données de licence. La base de données de supervision contient les tickets et les données des conversations. Si une base reste sur son serveur de base de données actuel, vous n’avez pas à la copier sur le nouvel ordinateur myContactCenter ; une sauvegarde récente reste toutefois nécessaire.

Créer une sauvegarde dans l’Administration sauvegarde uniquement la base de données de configuration, pas l’installation complète. La restauration se fait avec les outils du système de base de données ; voir Sauvegarder et entretenir la base de données.

Fichiers et paramètres	Ce que vous devez transférer ou vérifier
`appsettings.json` des services concernés	Connexions aux bases de données, compte de service, points d’enregistrement, accès SIP et paramètres locaux particuliers ; conserver des copies comme référence pour les configurateurs
Enregistrements et messages vocaux	Le Cheminement pour le stockage des enregistrements configuré et, le cas échéant, `%ProgramData%\ilogixx GmbH\myContactCenter\Recording` sur l’ancien ordinateur du Routing Service
Rapports exportés automatiquement	Le Chemin de stockage des rapports ; ces fichiers ne font pas partie de la sauvegarde des bases de données
Autres fichiers personnalisés	Modèles personnalisés, fichiers de script, dictionnaires et fichiers auxquels des flows ou scripts accèdent par des chemins fixes
Journaux et sauvegardes	Répertoire du Logger et sauvegardes existantes, si vous souhaitez les conserver pour les justificatifs et le dépannage
Paramètres des postes de travail	Si les postes sont également déplacés, les profils utilisateur de l’Agent, de l’Administration et du Wallboard

Les annonces et la musique sont stockées dans le MediaPool local du Routing Service. Incluez ce répertoire dans votre inventaire. Les répertoires présents et les emplacements où les programmes enregistrent leurs paramètres sont décrits sous Dossiers, fichiers et journaux et Fichiers de paramètres.

3. Préparer les bases de données et les utilisateurs sur le système de destination

Si les bases de données sont déplacées, restaurez d’abord les bases sauvegardées sur les nouveaux serveurs de base de données. Sélectionnez ensuite exactement ces bases dans le Server Configurator. N’utilisez pas une nouvelle base vide à la place de la base restaurée.

Microsoft SQL Server

La sauvegarde d’une base de données utilisateur contient ses utilisateurs et droits, mais pas les connexions SQL correspondantes de l’instance. Lors d’une migration vers une autre instance, les connexions doivent également y exister et correspondre aux utilisateurs restaurés. Pour les connexions SQL, un nom identique ne suffit pas : SQL Server les associe au moyen d’un identifiant, le SID.

Distinguez les comptes suivants :

Compte	Rôle et vérifications lors de la migration
Connexion SQL sous Nom du compte dans le Server Configurator	Le configurateur et le serveur utilisent cette connexion pour la base de données de configuration. Une base de supervision sur SQL Server dispose d’une saisie distincte. Transférez les connexions, mots de passe et droits nécessaires, ou configurez un accès approprié.
Compte de service Windows, par exemple `DOMAINE\mycc-service`	Les services s’exécutent sous ce compte. Le Server Configurator configure également, pour le compte de service du serveur, une connexion Windows et un utilisateur avec `db_owner` dans les bases SQL. Vérifiez l’association après la restauration, surtout si le compte de service a changé.
`myContactCenterReport`	Connexion SQL et utilisateur pour les rapports, avec le rôle `db_datareader` dans la base de données de configuration. Le nom ne contient pas d’espace avant `Report`. Le Server Configurator crée une connexion absente et recrée l’utilisateur de la base pour cette connexion.
Autres comptes de base de données personnalisés	Par exemple pour des analyses ou interfaces. Transférez-les avec les droits nécessaires si ces applications restent utilisées.

Dans le fonctionnement décrit ici, le compte de service Windows ne remplace pas la connexion SQL du serveur. La connexion SQL saisie dans le configurateur doit rester disponible après l’installation. L’instance SQL doit autoriser l’authentification SQL Server ; voir Microsoft SQL Server.

Lors de la migration SQL, faites transférer les connexions SQL nécessaires avec leur SID et leurs informations de mot de passe, ou associez les utilisateurs existants à la bonne connexion. Un compte Windows local du nouvel ordinateur est une identité différente du compte homonyme de l’ancien ordinateur. Un compte de domaine inchangé évite ce changement d’identité ; ses droits sur l’ordinateur de destination doivent néanmoins être corrects.

Pour une vérification ciblée, cette requête affiche les utilisateurs et leur association directe aux connexions de l’instance dans la base myContactCenter concernée. Des droits d’administration SQL appropriés sont nécessaires pour afficher toutes les connexions requises :

SELECT
    databaseUser.name AS DatabaseUser,
    databaseUser.type_desc AS UserType,
    serverLogin.name AS ServerLogin
FROM sys.database_principals AS databaseUser
LEFT JOIN sys.server_principals AS serverLogin
    ON databaseUser.sid = serverLogin.sid
WHERE databaseUser.principal_id > 4
    AND databaseUser.type IN ('S', 'U', 'G')
    AND databaseUser.authentication_type_desc IN ('INSTANCE', 'WINDOWS');

L’absence de ServerLogin justifie de vérifier l’association ; la requête ne vérifie ni les mots de passe ni tous les droits d’accès. Pour les accès Windows, il faut également tenir compte des appartenances aux groupes.

Si une connexion appropriée existe déjà, un utilisateur existant de la base peut lui être associé. Exemple pour un utilisateur du compte de service : exécutez l’instruction uniquement dans la base concernée et remplacez les deux noms par vos noms réels.

ALTER USER [mycc-service] WITH LOGIN = [DOMAINE\mycc-service];

Vérifiez ensuite les rôles de base de données nécessaires. Ne supprimez pas systématiquement des utilisateurs ou connexions. Microsoft décrit le transfert des connexions SQL et la correction des utilisateurs orphelins : Transférer les connexions entre instances et corriger les utilisateurs orphelins.

Base de données de supervision sur PostgreSQL

Outre la base de données, sauvegardez et transférez les rôles, propriétaires et droits nécessaires. Un seul pg_dump ne transfère pas les rôles globaux ; vous pouvez utiliser pg_dumpall --globals-only pour ceux-ci. Vérifiez l’export généré avant de l’appliquer à un système de destination déjà utilisé. Voir PostgreSQL : pg_dumpall.

Le serveur utilise l’accès PostgreSQL saisi dans le configurateur. La configuration définit également le propriétaire et les droits pour le rôle du produit myContactCenterTicket. Vérifiez que les rôles nécessaires existent déjà pour la restauration et que les propriétaires et les droits sur les tables et séquences sont corrects. Après la migration, vous devez pouvoir lire les tickets existants et enregistrer de nouvelles conversations.

4. Configurer les programmes et services sur le nouvel ordinateur

Vérifiez les prérequis et installez les packages nécessaires sur l’ordinateur de destination.
Dans le Server Configurator, sélectionnez la base de configuration et la base de supervision existantes ou restaurées. Saisissez un nom de SQL Server également accessible depuis les postes de travail ; localhost ou . ne conviennent pas.
Saisissez le compte de service Windows et son mot de passe. Pour un compte local, utilisez le compte du nouvel ordinateur. Vérifiez aussi son accès aux partages et, le cas échéant, à la configuration Swyx.
Parcourez l’assistant de Démarrer jusqu’à Terminer. Vérifiez ensuite son journal et l’Observateur d’événements Windows. La page de fin ne prouve pas à elle seule la réussite de toutes les commandes de base de données.
Configurez les autres services déplacés avec leurs configurateurs : Dispatcher, Logger et Routing Service. Gardez le nouveau Routing Service arrêté jusqu’à la vérification de la configuration du serveur et au démarrage d’exploitation prévu.

La configuration détaillée est décrite sous Configurer le serveur et Dispatcher, Logger et Routing Service. Reprenez les paramètres locaux particuliers nécessaires depuis les fichiers de paramètres sauvegardés. Modifiez ces fichiers uniquement lorsque le service est arrêté ; ne reprenez pas sans vérification les anciens noms d’ordinateurs et comptes locaux.

Vérifiez le DNS et les pare-feu entre les composants concernés. Cela inclut l’accès SQL direct des postes de travail et, pour un Routing Service réparti, 6009/TCP sur le serveur myContactCenter ; le package Server n’ouvre pas lui-même ce port. L’aperçu complet figure sous Ports et connexions.

5. Adapter les adresses des serveurs et les chemins

Démarrez l’Administration et connectez-vous avec le nouveau nom de serveur via Ajouter serveur. Utilisez un compte d’administrateur existant de la base transférée. Les données d’identification d’une nouvelle installation ne s’appliquent pas automatiquement à une base transférée ; voir Démarrer et se connecter.

Dispatcher et configuration du serveur

Les adresses des serveurs sont enregistrées à deux endroits distincts :

Dans le Dispatcher Configurator : Serveur maître et Serveur de secours. Actualisez ces valeurs dans chaque Dispatcher et parcourez le configurateur jusqu’à Terminer.
Dans la configuration du serveur de l’Administration, onglet Standby, groupe Serveur du centre de contact : Master, Standby, Nom alternatif pour Master et Nom alternatif pour le Standby. Ces valeurs figurent dans la base transférée et peuvent donc encore contenir les anciennes adresses. Vérifiez et sauvegardez les adresses du système de destination. Le droit Répartiteur est nécessaire.

Pour un serveur unique, Master et Standby désignent le même nouveau serveur. Le Dispatcher communique aux clients les adresses de la configuration du serveur. Modifier uniquement le nom d’ordinateur dans le Dispatcher ne suffit donc pas.

Emplacements des fichiers et connexions

Vérifiez dans l’Administration :

Serveur › Cheminement pour le stockage des enregistrements : transférez le dossier existant ou saisissez un nouveau dossier accessible. Le Routing Service doit y avoir accès. Vérifiez aussi la lecture des enregistrements existants ; modifier un chemin ne déplace pas les fichiers.
Serveur › Chemin de stockage des rapports : transférez les fichiers existants et assurez l’accès en écriture du nouveau serveur.
PBX : installation téléphonique et connexion. Même si le PBX reste inchangé, les droits du compte de service et les adresses sources autorisées peuvent changer.
Envoi d’e-mails, boîtes aux lettres, bases de données externes et flows et scripts personnalisés : vérifiez les noms d’ordinateurs, partages et chemins locaux enregistrés.
Licences › Activation : un changement d’ordinateur peut nécessiter une nouvelle activation pour Activation après changement significatif du matériel. Le transfert de la base de licences ne remplace pas cette vérification ; voir Activation.

Pour les enregistrements et les messages vocaux, la base de supervision stocke le chemin du fichier de chaque enregistrement. Un nouveau Cheminement pour le stockage des enregistrements s’applique aux nouvelles prises ; il ne réécrit pas automatiquement les références aux anciens fichiers. Conservez les anciens chemins accessibles au nouveau Routing Service ou convenez d’une adaptation des références enregistrées avec le support. Vérifiez particulièrement les enregistrements stockés dans le dossier local Recording parce qu’un partage était inaccessible.

L’accès et le stockage sont décrits sous Onglet Serveur, Installation téléphonique et Bases de données externes.

6. Adapter les clients et les autres composants

Composant	Adaptation
Administration	Ajoutez directement le nouveau serveur myContactCenter. Un Dispatcher inchangé ne modifie pas cette connexion enregistrée.
Agent	Si le Dispatcher reste accessible à la même adresse, les points d’enregistrement restent inchangés. Pour une nouvelle adresse de Dispatcher, modifiez Point 1 et, le cas échéant, Point 2 sous Réglages › Paramètres spéciaux.
Wallboard	Si les adresses des Dispatchers ont changé, modifiez les points d’enregistrement avec le Wallboard Configurator ; vérifiez aussi, le cas échéant, un fichier de paramètres distinct dans le profil utilisateur.
Routing Service et Logger	Si les adresses des Dispatchers ont changé, actualisez les points d’enregistrement dans leurs configurateurs.
Rapports et tableaux de bord	Ils utilisent les paramètres de base de données du serveur connecté. En fonctionnement standard, aucune nouvelle connexion SQL distincte n’est à saisir sur le poste. Vérifiez néanmoins le DNS, l’accès SQL et `myContactCenterReport`.
Chat web et WebCallback	Si le Routing Service est déplacé, modifiez et testez la destination interne du reverse proxy ou l’adresse du hub utilisée. Voir Configurer la connexion du site web.

Fermez les clients concernés et redémarrez-les après la bascule. Si vous distribuez des valeurs par défaut dans le répertoire du programme Agent, tenez compte du fait qu’elles ne remplacent pas les points d’enregistrement déjà saisis par un utilisateur. Vérifiez donc également les profils utilisateur existants et les sessions sur serveur de terminaux ; voir Préréglages pour tous les utilisateurs.

Si le Routing Service est également déplacé sur un autre ordinateur ou réseau, vérifiez son compte SIP et, le cas échéant, PublicAddress et BindAddress. Ces valeurs figurent dans son fichier de paramètres.

7. Démarrer l’exploitation et valider la migration

Démarrez le serveur et le Dispatcher, puis le Logger et le Routing Service, et connectez les clients au système de destination. L’ancienne installation de production reste arrêtée. Effectuez ces vérifications avec un agent de test :

Statut des services affiche les ordinateurs et services attendus En ligne ; le Routing Service est enregistré auprès du PBX.
L’Agent et l’Administration se connectent au nouveau serveur. Vérifiez au moins un poste existant, pas seulement un poste nouvellement configuré.
Les appels entrants et sortants fonctionnent avec l’audio dans les deux sens ; l’accueil et la distribution utilisent les flows attendus.
Un rapport historique et un tableau de bord statistique lisent les données transférées sur le poste. Un rapport automatique peut être généré, enregistré et envoyé sur le serveur.
Les tickets et conversations existants sont lisibles. Un nouveau contact est enregistré dans la bonne base de supervision.
Les anciens messages vocaux ou enregistrements sont lisibles ; un nouvel enregistrement peut être sauvegardé et lu.
Les fonctions d’e-mail, fax, chat et rappel utilisées fonctionnent, y compris la connexion du site web. Les interfaces personnalisées et bases de données externes sont accessibles.
L’état des licences, le journal du Logger et l’Observateur d’événements Windows ne contiennent pas d’erreurs inexpliquées liées à la migration.

Vérifiez ensuite les sauvegardes régulières des deux bases de données et des emplacements de fichiers au nouvel emplacement. Mettez l’ancien ordinateur hors service uniquement après une validation documentée. En cas de problème, consultez Statut des services et En cas de problème.

Si vous devez revenir à l’ancien système

Arrêtez d’abord la nouvelle installation. Rétablissez les anciennes adresses des serveurs et Dispatchers ou les associations DNS, et utilisez un état cohérent des bases de données et des fichiers compatible avec l’ancienne version du programme.

Si des contacts de production ont déjà été traités sur le nouveau système, ils sont absents de la sauvegarde antérieure à la migration. Les envois, rappels et enregistrements peuvent également différer. Avant le retour, clarifiez donc avec le support comment conserver ces nouvelles données ; restaurer simplement l’ancienne sauvegarde peut perdre des données ou remettre en traitement des contacts déjà traités.