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 :
Architecture UCCE 11.6 OHA
Responsables de campagne actifs - StandBy
Numéroteurs actifs - Veille
BaImport - Pas de basculement
Étape 1. Assurez-vous que la fonctionnalité de réplication de 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 SQL, l'utilisateur 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éation de bases de données BA sur les deux serveurs de journalisation
Étape 2 : configuration du même utilisateur SQL local avec le rôle sysadmin sur les deux journaliseurs
Étape 3. Démarrez WebSetup sur LoggerA, modifiez le composant Logger et activez Outbound Option et Outbound High Availability.

Remarque : Assurez-vous de fournir le nom d'hôte des enregistreurs dans les champs Interface publique. Cette valeur doit correspondre au nom du serveur SQL sur le journal respectif.
Une fois WebSetup terminé, vous devez voir Publication créé et LoggerA SQL Server et Abonnement sur LoggerB.
Vérifiez-le à partir de SQL Server Management Studio (SSMS) sous Replication > Local Publications on LoggerA et Local Subscriptions on LoggerB.

Exécutez WebSetup sur LoggerB, modifiez le composant Logger et activez Outbound Option et Outbound High Availability.
La publication doit être créée sur LoggerB et l'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 Launch Replication Monitor Tool dans 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 second onglet Tracer Tokens et sélectionnez Insert Tracer. qui teste la latence entre le serveur de publication et le serveur de distribution et entre le serveur de distribution et l'abonné.

Cette option doit être coché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 présente 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 réparer avant la configuration OO HA.

Afin de supprimer le nom du serveur SQL, exécutez cette commande dans SSMS sur 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 l'Agent SQL Server à partir des services Windows et vérifiez le résultat de la requête SQL select @@servername.
Mise en garde : Utilisez cette procédure uniquement si WebSetup ne parvient pas à établir la 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 enregistreurs avec les valeurs de variable respectives.
EXEC sp_ba_create_replication @instance=, @publisher= , @subscriber= , @working_directory = , @login = , @pwd =


Si vous rencontrez l'erreur « Échec de CREATE DATABASE », vérifiez si le compte MSSQLSERVER dispose d'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 dispose d'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.

Mise en garde : Utilisez cette procédure uniquement si WebSetup ne parvient pas à établir la réplication et que les erreurs ne sont pas claires.
Exécutez cette procédure sur les bases de données BA des deux enregistreurs avec les 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 du serveur de distribution car des bases de données sont activées pour la réplication sur ce serveur ».
EXEC sp_dropdistributor @no_checks = 1, @ignore_distributor =1
Commentaires