Voix et communications unifiées : Cisco Unified Communications Manager (CallManager)

Résolution des problèmes avec DC Directory

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document explique comment résoudre des problèmes de réplication de répertoire entre les services de serveur de DC Directory que ce passage sur des serveurs Cisco CallManagers a impliqués dans une batterie.

Cette procédure est valide pour les serveurs Cisco CallManagers qui exécutent des versions 3.0(5a) à 3.3.x.

Remarque: Les scripts de DC Directory (1.0.7) mentionnés dans ce document sont utilisés seulement avec le Cisco CallManager 3.0(5a) à 3.3(2c).

Remarque: Pour le Cisco CallManager 3.3(3) et plus tard, la version de schéma de répertoire a changé. Par conséquent, les scripts sont déjà inclus dans le Cisco CallManager 3.3(3) et plus tard et vous n'ayez pas besoin de les télécharger. Si vous exécutez le Cisco CallManager 3.3(3) ou plus tard, référez-vous à la procédure dans la section de reconfiguration.

Cette liste décrit les symptômes associés avec ce problème :

  • Le serveur d'éditeur de Cisco CallManager a des données d'utilisateur correctes. Cependant, un ou plusieurs serveurs d'abonné de Cisco CallManager ou n'ont pas des données d'utilisateur, ou les données d'utilisateur sont périmées avec la base de données de l'éditeur.

  • Le service de DC Directory sur le serveur d'éditeur de Cisco CallManager prend un longtemps à la mise en route (semble caler ou s'arrêter sur la mise en route).

  • Les erreurs de réplication de DC Directory sont enregistré aux serveurs d'éditeur et/ou d'abonné de Cisco CallManager dans le visualisateur d'événements d'application.

  • Un examen des expositions de C:\dcdsrvr\run\dcx500\dcx500.out en double et/ou des accords non valides de réplication.

Remarque: Se connecter du serveur de DC Directory de message de DC Directory A ÉTÉ CALMÉ dans le journal d'application du Cisco CallManager Publisher pendant la sauvegarde avec des BARRES est normal. Calmé implique que le DC Directory ne peut pas obtenir assez de ressources du serveur parce qu'un autre processus contrôle actuellement la plupart des ressources. Fondamentalement, le Cisco CallManager fait une pause le service de DC Directory jusqu'à ce qu'il se termine ce qu'il fait. Ainsi tandis qu'une tâche est effectuée sur le serveur de Publisher qui a besoin de beaucoup de ressources, cette erreur peut être normale.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

  • Cisco CallManager 3.0(5a) 3.3(2c) sur tous les serveurs dans la batterie.

  • Un serveur encastré de DC Directory est utilisé comme mémoire de répertoire pour tous les serveurs dans la batterie.

Les informations contenues dans ce document ont été créées à partir des périphériques dans un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est vivant, assurez-vous que vous comprenez l'impact potentiel de n'importe quelle commande.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Problème

La présence des accords non valides de réplication fait développer la base de données de DC Directory (fichiers dans C:\dcdsrvr\run\dcx500\database) extrêmement grande (plus de 100 Mo). Ceci fait prendre le DC Directory un grand nombre de temps à l'arrêt et à la mise en route. Ceux-ci reproduisent et les accords non valides sont provoqué par en raison d'une de ces raisons :

  1. Le client réinstalle le serveur d'application de Cisco Customer Response (CRA) (ou un abonné de Cisco CallManager) un ou plusieurs fois (chacun réinstalle du serveur/du serveur Cisco CallManager de CRA fait avoir l'éditeur un nouvel accord de réplication à l'abonné).

  2. Un serveur de CRA (ou un abonné de Cisco CallManager) existe déjà, et est désarmé sans représentation de la procédure de reconfiguration de DC Directory dans la batterie de Cisco CallManager.

    Remarque: Quand un noeud de répertoire est retiré d'une batterie de Cisco CallManager, les accords de réplication de DC Directory à l'abonné retiré ne sont pas automatiquement nettoyés.

  3. La commande d'avvid_scfg est manuellement exécutée sur l'abonné plus d'une fois (par exemple, une procédure partielle de reconfiguration de DC Directory est tentée).

    avertissement Avertissement : N'exécutez jamais une procédure partielle de reconfiguration de DC Directory, (n'exécutez par exemple, jamais l'avvid_scfg s'il n'est pas poursuivi par cleandsa sur l'éditeur et le serveur de CRA, et/ou l'abonné de Cisco CallManager).

La cause principale de la croissance de la base de données à de telles grandes tailles est que des essais de DC Directory de sauvegarder l'état pour chaque exécution de réplication qu'elle n'exécute pas. Sur une période, ces informations d'état enregistrées pour les accords non valides de réplication font devenir la base de données plusieurs centaines de mis-bande.

Ne confondez pas la réplication de DC Directory avec la réplication de SQLServer. Ils sont deux processus complètement indépendants.

Si vous exécutez une réinstallation d'un abonné de Cisco CallManager ou d'un serveur de CRA 2.2(4) et d'un plus tôt, ou le serveur de CRA 3.0(1), vous devez exécuter la procédure de reconfiguration de DC Directory sur tous les Noeuds dans la batterie. Ceci inclut les serveurs autonomes de CRA. Commencez par l'éditeur de DC Directory.

Solutions

Tandis que vous effectuez ces tâches, vous devez être :

  • Directement à la console des serveurs du serveur de convergence de medias (MCS), connectés par un commutateur de clavier/vidéo/souris (KVM).

    OU

  • Connecté par l'intermédiaire du telnet aux serveurs.

La représentation de ces tâches de particularité tandis que vous êtes connecté par une connexion client de services de terminaux n'a pas été entièrement testée, et peut produire des résultats inattendus. Cisco recommande que vous programmiez un temps d'arrêt afin d'exécuter la procédure. Les deux étapes impliquées sont :

  1. Installation

  2. Reconfiguration

Installation

Terminez-vous ces étapes pour l'installation :

  1. Téléchargement DCDScripts.1-0-7.exe du site Web de Cisco CallManager version 3.2 (clients enregistrés seulement). Téléchargez seulement ces scripts si vous exécutez des versions antérieures à 3.3 de Cisco CallManager. Il n'y a aucun besoin de télécharger des scripts sur des versions 3.3 et ultérieures car ils sont inclus et fondent dans le dossier de c:\dvdsrvr\bin. Si vous installez et exécutez le fichier DCDScripts.1-0-7.exe sur de plus nouvelles versions de Cisco CallManager, ceci fait échouer le système.

  2. Copiez et exécutez DCDScripts.1-0-7.exe sur tous les Noeuds dans la batterie de Cisco CallManager, et sur les serveurs d'applications CRA/CRS. Recevez les valeurs par défaut quand vous êtes incité à faire ainsi, et le clic défont la fermeture éclair.

    Remarque: Assurez-vous que vous exécutez les scripts pendant des heures creuses afin d'éviter l'utilisation du CPU élevé.

Reconfiguration

Il y a deux scénarios possibles quand vous allez modifier votre DC Directory après installation :

  1. Quand la base de données de DC Directory est plus grande que la mi-bande 100, référez-vous au DC Directory de modification sur la solution de Cisco CallManager Publisher (une plus grande mi-bande que 100 de base de données) dans ce document.

  2. Quand la base de données de DC Directory est moins de mi-bande 100, référez-vous au DC Directory de modification sur la solution de Cisco CallManager Publisher (mi-bande de 100 de base de données moins) dans ce document.

Modifiez le DC Directory sur le Cisco CallManager Publisher (mi-bande de 100 de base de données plus)

Ces étapes s'assurent que vos données d'utilisateur dans le DC Directory sur le serveur Cisco CallManager d'éditeur sont sauvegardées en cas de panne pendant ces étapes. Ces étapes aident également quand la base de données de DC Directory est plus grande que la mi-bande 100 (C:\dcdsrvr\run\dcx500\database).

Utilisez les étapes dans cette section si vous éprouvez ceci installez l'erreur pendant une mise à jour de Cisco Unified Communications Manager : Le serveur de DC Directory est dans le mauvais état ou ne peut pas être terminé proprement.

Remarque: Vous devez désactiver le service du Cisco Security Agent (CSA) avant que vous installiez, désinstalliez, ou amélioriez n'importe quel logiciel (système d'exploitation y compris), sur le Cisco CallManager. Vous devez désactiver l'agent à l'aide de la méthode qui est décrite en désactivant et en réactivant le service de Cisco Security Agent. Assurez-vous que le service ne devient pas réactivé à tout moment pendant l'installation ou la mise à jour. Le manque de faire ainsi peut poser des problèmes avec l'installation ou la mise à jour. Après que l'installation ou la mise à jour de logiciel, vous doive réactiver CSA avant qu'il commence à surveiller le serveur de Cisco Unified CallManager de nouveau.

  1. Sauvegardez vos informations de répertoire courant. Utilisez l'utilitaire de sauvegarde MCS, ou exécutez la commande de sauvegarde de /y C:\dcdsrvr\backup de dcbckdib d'une invite de commande de DOS.

    Remarque: Le répertoire de C:\dcdsrvr\backup doit exister avant que vous exécutiez la commande de sauvegarde de /y C:\dcdsrvr\backup de dcbckdib.

  2. Sur le serveur d'éditeur, tandis qu'ouvert une session en tant qu'administrateur, ouvrez une invite de commande. Afin de faire ainsi, sélectionnez le Start > Run, et écrivez le cmd.

  3. Introduisez la commande de servernamepassword avvid_migrate_save.cmd, et appuyez sur n'importe quelle touche une fois incité.

    La sortie de cette commande semble semblable à cette sortie :

    C:\>avvid_migrate_save jayas-w2k ciscocisco
    A subdirectory or file C:\dcdsrvr\log already exists.
    
    ****************************************
    *                                      *
    * -- CISCO User Preferences Support -- *
    *                                      *
    ****************************************
    
    A subdirectory or file C:\dcdsrvr\suspense already exists.
    
    Run the perl script avvid_migrate_save.pl
    A subdirectory or file C:\dcdsrvr\log already exists.
    A subdirectory or file C:\dcdsrvr\run\DCX500\config\Migration-Backup 
    already exists.
    Saving User Information...
    Saving Profile Information...
    Saving Apps20 Information...
    Saving Admin Information...
    Saving PA node Information...
    Saving E911 node Information...
    Saving systemProfile...
    Saving MITRA data...
    Saving Groups data...
    
    C:\>
  4. Arrêtez le service de DC Directory. Écrivez l'arrêt net dcdirectory de l'invite de commande.

  5. Exécutez cleandsa.cmd ou deletedib.cmd, si cleandsa.cmdreports qu'il n'est pas pris en charge.

  6. Exécutez avvid_migrate_cfg.exe.

    (Utilisation mot de passe d'avvid_migrate_cfg)

  7. Exécutez avvid_migrate_restore.cmd.

    (Utilisation nom du serveur DCDpassword d'avvid_migrate_restore)

  8. Exécutez reconfig_cluster.cmd.

    (Utilisation — reconfig_cluster DCDAdminPassword)

    Cette commande établit des accords de réplication à tous les abonnés de Cisco CallManager. Vous n'avez pas besoin de n'effectuer aucune tâche sur les abonnés l'uns des de Cisco CallManager.

Modifiez le DC Directory sur le Cisco CallManager Publisher (mi-bande de 100 de base de données moins)

Terminez-vous ces l'étape afin de modifier le DC Directory dans l'éditeur de Cisco CallManager quand la base de données de DC Directory est moins de mi-bande 100 (C:\dcdsrvr\run\dcx500\database).

Exécutez reconfig_cluster.cmd.

Cette commande établit des accords de réplication à tous les serveurs d'abonné de Cisco CallManager. Vous n'avez pas besoin de n'exécuter aucune étape supplémentaire sur les abonnés l'uns des de Cisco CallManager.

Modifiez le DC Directory sur le serveur CRA/CRS

Terminez-vous ces étapes afin de modifier le DC Directory sur le serveur CRA/CRS :

  1. Arrêtez le service de DC Directory.

  2. Exécutez les états cleandsa.cmd ou deletedib.cmdif cleandsa.cmd qu'il n'est pas pris en charge.

  3. Exécutez avvid_scfg.cmd.

    (Utilisation — reconfig_cluster DCDAdminPassword)

    Remarque: Si le réseau a un serveur Cisco CallManager simple avec ou sans CRA/CRS coïmplanté, vous devez exécuter reconfig_cluster.cmd. Dans ce cas le donot exécutent les étapes répertoriées pour le serveur de Cisco CRA/CRS.

    Remarque: Si vous promouvez, réinstallez, ou ajoutez un nouveau serveur Cisco CallManager 3.2(2c) ou plus tôt, ou CRA 2.2(4) ou plus tôt, et CRA 3.0(1), vous devez copier et exécuter DCDScripts.1-0-7.exe comme décrit dans la section d'installation.

Modifiez l'ID utilisateur dans le Cisco CallManager utilisant le DC Directory

L'ID utilisateur est utilisé pour identifier chaque utilisateur dans le Cisco CallManager. Par défaut, le Cisco CallManager ne te permet pas pour changer l'ID utilisateur. S'il y a lieu, vous pouvez le changer utilisant l'administrateur de DC Directory avec ces étapes.

  1. La procédure de connexion à l'administrateur de DC Directory du début > programme > administrateur de DC Directory.

  2. Utilisateurs de clic.

    La liste d'utilisateurs apparaît du côté droit de la fenêtre. Double-cliquer sur l'utilisateur pour lequel l'ID utilisateur devrait être modifié.

  3. Allez à l'onglet de courrier électronique et le clic modifient.

  4. Changez l'ID utilisateur spécifié contre la valeur d'Internet, puis cliquez sur Apply et L'APPROUVEZ.

Terminez-vous ces étapes pour vérifier si l'ID utilisateur est changé.

  1. Ouvrez la page d'administration de Cisco CallManager.

  2. L'utilisateur choisi > ajoutent un nouvel utilisateur.

  3. Cliquez sur la recherche de base avec le nouvel ID utilisateur et la vérifiez si l'ID utilisateur a changé.

Problème - Incapable de supprimer un utilisateur du DC Directory

Quand des essais d'un utilisateur pour supprimer un utilisateur dans le DC Directory, ce message d'erreur est reçus :

Could not delete user. UserID = "<username>"

Solution

Cette question peut se produire si le service de DC Directory a été arrêté. Afin de résoudre le problème, redémarrez le service de serveur de DC Directory du Start > Programs > Administrative Tools > Services. Vous pouvez alors supprimer l'utilisateur.

Remarque: Vous pouvez utiliser la correspondance de modèle aussi bien qu'exiger - la correspondance afin de rechercher le nom de service. Utilisez la correspondance de modèle, telle que des symboles basés par masque comme ? , -, *, %, si le nom de service a les espaces.

Erreur : Aucun blocs de gestion libres de connexion - connexion refusée.

Ce message d'erreur de DC Directory apparaît sur le visualisateur d'événements :

Event Type:	Warning
Event Source:	DCDirectory
Event Category:	Configuration 
Event ID:	9415
Date:		1/30/2009
Time:		11:10:31 AM
User:		N/A
Computer:	QPUB
Description:
(BASE IL NEW CONNECT(47) Proc 88, Sev 14)
           No free connection control blocks - connection refused. This
           indicates that the maximum number of simultaneous TCP/IP
           connections has been reached, and further connection
           attempts will fail until one of the existing connections
           has been closed.
             Socket ID                D4859209
             Component                LDAP
             Number of CBs configured 504

Solution

De la version 3 et ultérieures, le DC Directory emploie l'option de socket de keepalive afin de détecter les connexions mortes. Cependant, si le signal de keepalive est retardé au moins pendant une milliseconde, il génère l'erreur puisque quelques connexions ne sont pas libérées à l'heure et le système peut atteindre la limite pour juste un instant très petit. Ce comportement fait également continuer des clients derrière des Pare-feu à ouvrir de nouvelles connexions quand le Pare-feu chronomètre les connexions de veille. En outre, quand les clients sont redémarrés, de vieilles connexions ne sont pas démolies sur le côté serveur, qui fait dépasser le DC Directory sa limite maximum des connexions permises de LDAP de 500 au fil du temps.

Les effets pratiques de ces connexions ouvertes est petit, et ils n'entraînent aucun effet opérationnel. Ils entraînent un temps système minutieux sur le système d'exploitation et le compte vers la limite configurée sur les connexions d'arrivée de LDAP.

Si vous n'éprouvez aucun effet en votre Cisco CallManager, ce comportement ne représente pas un problème. Comme cité précédemment, ce genre d'erreur peut provoquer des comportements, tels que des problèmes pour que les utilisateurs ouvrent une session à DCD ou à IPCC. Si c'est le cas, vous voyez les centaines de répétition des erreurs de périodes.

Si vous détectez que votre système est affecté par cette erreur, ces connexions C.C Directory/LDAP peuvent être forcées ferment. Afin de faire ceci, arrêtez et redémarrez le serveur de DC Directory, sous des services. Référez-vous au CallManager ne peut pas ouvrir le DC Directory pour que les étapes redémarrent le serveur de DC Directory.

Erreur 1096 : L'AvDSAD n'a pas un contrôleur de domaine pour le domaine et ne pourrait pas obtenir un à partir du Répertoire actif.

Ce message d'erreur apparaît sur le visualisateur d'événements :

Event Type:	Error
Event Source:	CiscoUnity_DSAD
Event Category:	Warning 
Event ID:	1096
Date:		08/05/2009
Time:		4:09:19 PM
User:		N/A
Description:
Computer:	CLUSTER8-UNITY
Description:

The AvDSAD does not have a domain controller for the domain, and could not 
get one from Active Directory. Ensure that a domain controller exists for this
domain, that no DNS issues exist, and that The Cisco Unity service that monitors 
Active Directory (AvDSAD) account has the proper rights.

Solution

Afin d'éliminer cette erreur, ouvrir l'outil DC/GC et exécuter une force rebranchent. Dans certains cas, DCGC rebranchent l'outil affichent un domaine vide. Dans ce cas, terminez-vous ces étapes afin de supprimer que C.C de la base de données et puis exécutez une force rebranchent.

  1. Choisissez le début > les programmes > le gestionnaire SQL > d'entreprise.

  2. Développez les gens du pays > la base de données > l'UnityDb > les Tableaux.

  3. Clic droit ADDomain > Tableau ouvert > retour toutes les lignes.

  4. Supprimez l'entrée pour le domaine vide.

  5. Ouvrez l'outil DCGC et exécutez une force rebranchent avec le C.C.

Événement 9415 : Aucun blocs de gestion libres de connexion - connexion refusée.

Dans les journaux d'application de Cisco CallManager, ce message d'erreur apparaît :

Event Type:	Warning
Event Source:	DCDirectory
Event Category:	Configuration 
Event ID:	9415
Date:		mm/dd/yy
Time:		2:42:25 AM
User:		N/A
Computer:	abc
Description:
(BASE IL NEW CONNECT(47) Proc 88, Sev 14)
           No free connection control blocks - connection refused. This
           indicates that the maximum number of simultaneous TCP/IP
           connections has been reached, and further connection
           attempts will fail until one of the existing connections
           has been closed.
             Socket ID                24E27308
             Component                LDAP
             Number of CBs configured 504

Solution

Afin de résoudre ce problème, augmentez le MAXLDAPConnections dans C:\dcdsrvr\run\dccustom.ini à 2000, et redémarrez le service DCD.


Informations connexes


Document ID: 30002