• Diagnostiquer les problèmes de carnet d’adresses OCS

    Dans beaucoup de déploiements ou de maquettes, on peut être confronté à l’erreur Office Communicator indiquant qu’il est impossible de télécharger le carnet d’adresses. Je vais essayer ici de donner quelques pistes assez simple pour trouver l’origine du problème.

    Voici la liste des points que je vérifie en général :

    1. Vérifier dans l’observateur d’événements sur les Front End qu’il n’y a pas d’erreur concernant la génération du carnet d’adresses tous les jours (généré en général très tôt le matin).
    2. Vérifier que le partage de fichiers correspondant au carnet d’adresses contient bien les fichiers du carnet d’adresses générés tous les jours. Si ce n’est pas le cas, il se peut qu’il faille redémarrer les Front End un à un.
    3. Côté client, activer le logging dans Office Communicator (Tools, Options, General, Turn on logging in Communicator)
    4. Fermer et ouvrir une session avec OC, aller dans le répertoire %USERPROFILE%\Tracing et ouvrir avec le bloc notes le fichier Communicator-uccapi-X.uccapilog
    5. Rechercher “absInternalServerUrl” et copier l’URL dans Internet Explorer (j’insiste sur Internet Explorer et pas autre chose, c’est important). Un popup d’authentification AD doit apparaitre, et une fois authentifié avec son compte, l’utilisateur doit avoir une erreur 403 Access Denied. Il est très important que le proxy de l’entreprise ne demande pas une authentification avant l’authentification demandée par le site Web
    6. Pour vérifier si le problème ne vient pas du certificat, désactiver les vérifications de CRL dans Internet Explorer (Options Internet, Avancé, Vérifier la révocation des certificats de l’éditeur et du certificat serveur).
    7. Fermer OC et l’ouvrir à nouveau. Si l’erreur disparait, le problème vient de la vérification de la CRL pour le certificat
    8. Ouvrir les propriétés du certificat configurés sur IIS sur les Front End et vérifier qu’il y a des Certificate Distribution Points, et vérifier avec Internet Explorer que la CRL HTTP est téléchargeable sans authentification
    9. Si la CRL est téléchargeable, l’ouvrir pour vérifier les dates d’application de la CRL pour voir si elle est encore valide.
    10. Si tous ces éléments sont bons, il faut aussi vérifier sur le téléchargement d’un fichier de type LSABS est possible. Pour cela, prendre le nom d’un des fichiers dans le partage de fichiers ABS, et tester avec Internet Explorer de le télécharger via l’URL https://<URL Pool>/Abs/Int/Files/<Nom du fichier LSABS>. Si une erreur HTTP 500 est retournée, il faut redémarrer l’Application Pool qui héberge la Virtual Directory Abs dans IIS.

    Ces étapes sont des vérifications simples à réaliser et permettent de résoudre normalement 95 % des problèmes liés au téléchargement du carnet d’adresses.

    Il faut aussi savoir que depuis quelques mois, le comportement d’Office Communicator a changé : il ne télécharge plus le carnet d’adresse dès son démarrage mais dans un intervalle aléatoire compris entre 0 et 60 minutes. Ce comportement peut être modifié par clés de registres. Pour plus d’informations : http://support.microsoft.com/kb/972403/en-us

  • Contenu du champ FROM lors de l’utilisation du pont de conférence OCS

    Lorsqu’OCS est déployé avec les fonctionnalités de téléphonie, il se peut que le numéro de l’organisateur de la conférence ne soit pas pas présenté aux personnes appelées sur leur téléphone portable ou fixe connecté au PSTN.

    Lorsqu’un utilisateur Office Communicator initie une conférence audio depuis OC et qu’il invite des personnes extérieures, le Mediation Server va servir à faire la passerelle entre le monde OCS et le réseau externe. Dans le cas d’une conférence, le Mediation Server recevra comme information que l’appelant est sip:Utilisateur.Appelant@contoso.com et non pas le numéro de l’appelant, par exemple +33122334455.

    Cela peut avoir un effet non souhaité : la passerelle derrière le Mediation Server ne comprends pas le contenu du champ et n’effectue pas l’appel

    Il peut y avoir plusieurs approches pour résoudre ce problème :

    1. Créer une règle sur la passerelle en indiquant que tous les numéros d’appelant non reconnus ou contenant “@” seront remplacés par le numéro du standard de l’entreprise
    2. Si la passerelle le permet et si tel est le souhait, créer une règle qui permet de récupérer le numéro de téléphone de l’appelant via une requête à Active Directory en fonction de son adresse SIP contenue dans le champ FROM, et émettre l’appel vers l’extérieur en utilisant le numéro de l’utilisateur
  • Comportement du partage de page Web dans Live Meeting

    Dans Live Meeting, il est possible de partage le bureau, une application, d’utiliser un tableau blanc, partager une page Web…

    Il faut savoir que le partage de page Web a quelques limitations. En effet, une page Web partagée dans Live Meeting est en réalité affichée sur tous les postes qui ont la console Live Meeting, et dans certains cas il se peut que certains liens ne fonctionnent pas. Par exemple, l’utilisateur qui partage la page Web clique sur un lien pour aller sur une autre page, va voir la nouvelle page mais il se peut que les autres participants restent sur la page initiale.

    Ce problème se produit uniquement dans le cas où les liens ne sont pas de simples liens “A HREF” : si du JavaScript s’occupe de gérer la navigation, le lien ne fonctionnera pas.

    Cela est lié au fait que le partage de page Web dans Live Meeting restreint l’utilisation du JavaScript : le code n’est pas exécuté sur les postes de travail de tous les participants, pour éviter des problèmes de sécurité. Par exemple, si l’organisateur prépare une page Web avec un script JavaScript réalisant une action mal intentionnée et la partage, le script ne sera pas exécuté sur les postes.

    Conséquence de cela, pour partager une page Web de manière complète avec et être sûr du comportement, le plus simple est d’utiliser la fonctionnalité de Partage d’Application dans Live Meeting, en choisissant de partager le navigateur Web.