Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit comment configurer et dépanner Cisco Unified Contact Center Enterprise (UCCE) Outbound Option High Availability (OOHA).
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
La fonctionnalité Outbound Option High-Availability (OOHA) a été introduite dans la version UCCE 11.6. OOHA est une fonctionnalité facultative. À partir de la version UCCE 11.6, le processus Campaign Manager peut être redondant avec le modèle de basculement Active-StandBy. Lorsque OOHA est activé dans WebSetup, le système effectue automatiquement une réplication transactionnelle bidirectionnelle SQL entre les bases de données BA_A et BA_B.
Ces tables sont répliquées :
Responsables de campagne actifs - StandBy
Numéroteurs actifs - StandBy
BaImport - Pas de basculement
Étape 1. Assurez-vous que la fonctionnalité de réplication SQL Server est activée.
setup.exe /q /Features=Replication /InstanceName=/ACTION=INSTALL /IAcceptSQLServerLicenseTerms
Étape 2. Vérifiez que le compte d'utilisateur SQL Server est configuré.
Étape 3. Dans l'utilisateur SQL NT AUTHORITY\SYSTEM doit avoir le rôle sysadmin.
Étape 4. Le nom d'hôte du serveur de journalisation et le nom de serveur SQL Server (@@servername) doivent être identiques.
Étape 1. Créez des bases de données BA sur les deux serveurs de journalisation.
Étape 2. Configurez le même utilisateur SQL local avec le rôle sysadmin sur les deux journaux.
Étape 3. Démarrez WebSetup sur LoggerA, modifiez le composant Logger et activez Outbound Option et Outbound High Availability.
Note: Assurez-vous de fournir le nom d'hôte Loggers dans les champs de l'interface publique Logger. Cette valeur doit correspondre au nom du serveur SQL sur chaque enregistreur.
Une fois WebSetup terminé, vous devez voir Publication créée et LoggerA SQL Server et Abonnement sur LoggerB.
Vérifiez-la à partir de SQL Server Management Studio (SSMS) sous Replication > Local Publications on LoggerA and Local Subsciptions on LoggerB.
Exécutez WebSetup sur LoggerB, modifiez le composant Logger et activez Outbound Option et Outbound High Availability.
La composition doit être créée sur LoggerB et Abonnement sur LoggerA.
Cette image montre la publication et l'abonnement créés sur le serveur LoggerB.
Cette image montre la publication et l'abonnement créés sur le serveur LoggerA.
Sélectionnez Lancer l'outil Replication Monitor à partir de SSMS pour vérifier l'état de la réplication.
L'état de la réplication doit être OK.
Développez l'éditeur pour obtenir plus d'informations sur les performances et la latence.
Accédez au deuxième onglet Jetons de trace et sélectionnez Insérer un traceur. Cela teste la latence entre Publisher et Distributor et entre Distributor et Subscriber.
Cette option doit être vérifiée sur les deux enregistreurs.
Ouvrez SSMS et exécutez cette requête SQL.
SELECT @@servername
Comparez le résultat de la requête avec le nom d'hôte du serveur Windows. Ils doivent correspondre.
Cette image montre un scénario de problème lorsque le nom d'hôte de LoggerA et le nom du serveur SQL ne correspondent pas. Assurez-vous de le corriger avant de configurer OO HA.
Afin de supprimer le nom de serveur SQL, exécutez cette commande dans SSMS contre la base de données maître.
EXEC sp_dropserver @server=
Pour ajouter un nouveau nom de serveur SQL, exécutez cette commande.
EXEC sp_addserver @server=, @local=LOCAL
Redémarrez SQL Server et SQL Server Agent à partir des services Windows et vérifiez le résultat de sélectionner @@servername Requête SQL.
Attention : Utilisez cette procédure uniquement si WebSetup ne peut pas établir de réplication et que les erreurs ne sont pas claires.
Exécutez cette procédure stockée sur les bases de données BA des deux journaux avec des valeurs de variable respectives.
EXEC sp_ba_create_replication @instance=, @publisher= , @subscriber= , @working_directory = , @login = , @pwd =
Si vous rencontrez une erreur « Échec de la création de la base de données », vérifiez si le compte MSSQLSERVER a un accès complet au répertoire de travail SQL.
Cette image affiche les erreurs respectives dans les journaux du serveur SQL.
Assurez-vous que le compte MSSQLSERVER a un accès complet au répertoire de travail SQL.
Assurez-vous que la publication et l'abonnement sont créés sur chaque serveur SQL Logger.
Attention : Utilisez cette procédure uniquement si WebSetup ne peut pas établir de réplication et que les erreurs ne sont pas claires.
Exécutez cette procédure avec les bases de données BA des deux journaux avec des valeurs de variable respectives.
EXEC sp_ba_remove_replication @instance =, @subscriber =
Vérifiez si les publications sont supprimées des deux serveurs SQL de journalisation.
Pour effacer complètement SQL Server de la configuration de réplication, vous devez supprimer manuellement les abonnements et supprimer les bases de données de distribution sur les deux serveurs SQL Logger.
USE master EXEC sp_dropdistpublisher @publisher=; EXEC sp_dropdistributiondb @database=distribution; EXEC sp_dropdistributor; GO
Dans certains cas, la dernière commande peut échouer avec le message d'erreur « Impossible de supprimer le nom du serveur en tant que serveur de publication de distribution car il y a des bases de données activées pour la réplication sur ce serveur ».
EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1