Après l’installation de l’Add-In Outlook permettant de planifier des réunions Communicator et Live Meeting, il y a un cas où Outlook peut planter en affichant les messages tels que :
Ce problème peut survenir si les outils d’administration Exchange Server 2003 sont installés sur le poste de travail. La solution est très simple : il suffit de désinstaller les outils d’administration Exchange Server 2003.
Lors de fédération OCS entre sociétés, on trouve de temps à autres le besoin d’avoir la liste de tous les contacts de la société fédérée. Cela se produit par exemple lorsqu’une société et sa filiales, qui ont deux infrastructures séparées, sont fédérées. Alors qu’une simple des comptes utilisateurs en contacts via IIFP/MIIS/ILM ou autre permet de peupler de manière simple la GAL Exchange, il s’avère que le peuplement du carnet d’adresses Office Communicator peut être plus délicat.
En effet, une solution consiste à synchroniser l’attribut msRTCSIP-PrimaryUserAddress. Or, dans ce cas, il apparaîtra un problème : l’ouverture de l’onglet Communications dans les propriétés du contact dans Active Directory affichera une erreur, puisque du point de vue OCS, l’état du contact ne sera pas cohérent. Cela tout simplement parce que le contact aura l’attribut msRTCSIP-PrimaryUserAddress de configuré mais pas les autres attributs utilisés par OCS.
Pour éviter ce problème mais néanmoins avoir la liste des utilisateurs de la société fédérée dans le carnet d’adresses OCS, la solution est de synchroniser le contenu de msRTCSIP-PrimaryUserAddress (en source) dans un attribut tel que extensionAttribute15 (en cible), et de configurer ensuite OCS pour qu’il prenne en compte le contenu de cet attribut. De cette manière, lors de la synchronisation du carnet d’adresses, les contacts dans Active Directory seront peuplés dans le carnet d’adresses OCS. Un utilisateur OC pourra donc facilement rechercher un contact depuis la zone de recherche dans OC et communiquer avec lui.
Pour modifier la configuration du carnet d’adresses, il faut modifier une table SQL dans l’instance où sont hébergées les bases de données du pool OCS.
La procédure est la suivante :
- Se connecter à l’instance SQL qui contient les bases de données du pool
- Selectionner la base “rtc” comme base active : USE RTC;
- Ajouter une ligne à la table indiquant de prendre en compte le contenu de l’attribut extensionAttribute15: INSERT INTO AbAttribute VALUES (254, ’extensionAttribute15’, 0x08020800);
Ensuite, lancer une génération complète du User Replicator à partir d’un Front End, en exécutant la commande ABServer –RegenUR. L’outil ABServer se trouve par défaut dans C:\Program Files\Microsoft Office Communications Server 2007 R2\Server\Core.
Dans le cas d’un serveur OCS Standard Edition, il est possible d’utiliser l’outil en ligne de commandes OSQL pour se connecter à la base de données.
Il est possible que l’affichage des rapports du Monitoring Server OCS 2007 R2 se passe mal et qu’une erreur apparaisse à la place, du style :
An error has occurred during report processing. (rsProcessingAborted)
Cannot impersonate user for data source ‘CDRDB. (rsErrorImpersonatingUser)
Logon failed. (rsLogonFailed)
For more information about this error navigate to the report server on the local server machine, or enable remote errors.
En se connectant depuis le serveur SQL et en accédant à l’URL de Reporting Services, le message est intéressant:
An error has occurred during report processing. (rsProcessingAborted)
Cannot impersonate user for data source ‘CDRDB. (rsErrorImpersonatingUser)
Logon failed. (rsLogonFailed)
Logon failure: the user has not been granted the requested logon type at this computer. (Exception from HRESULT: 0x80070569)
La dernière ligne donne la solution : le problème vient du fait que le compte de service utilisé pour accéder à la base de données SQL n’ait pas les droits de se connecter localement au serveur SQL. Ce compte de service est normalement RTCReportPack.
Pour résoudre le problème, il suffit de se connecter sur le serveur SQL où Reporting Services est déployé, ouvrir la console Local Security Policy, et ajouter le droit “Allow log on localy” pour le compte RTCReportPack.
Une erreur classique aussi est d’avoir oublié de positionner l’option “Password Never Expires” sur le compte de service RTCReportPack, cela ayant pour conséquence d’avoir l’accès au CDR ou QoE ne fonctionnant plus quelques semaines après l’installation.
Lorsqu’on installe le Deployment Validation Tool d’OCS 2007 (disponible sur http://www.microsoft.com/downloads/details.aspx?FamilyID=3596a10d-65cc-4cca-8470-3f23d5ea55b2&DisplayLang=en) ou OCS 2007 R2 (disponible dans le Resource Kit sur http://www.microsoft.com/downloads/details.aspx?FamilyID=b9bf4f71-fb0b-4de9-962f-c56b70a8aecd&DisplayLang=en), il se peut que l’Auto Answering Agent ne fonctionne pas : lorsqu’on l’appelle, il est impossible d’entendre “Rita” parler.
Cela peut se produire si le compte utilisé pour faire fonctionner l’AAA a un profil qui n’a pas les Regional Settings au format en-US. Si tel est le cas, il suffit d’ouvrir une session sur la machine où est installée l’AAA avec le compte associé, et modifier les Regional Settings pour mettre English (United States). Il ne reste plus qu’à redémarrer le service associé au DVT et tout devrait fonctionner.
Cela est aussi valable pour les Agents et l’Organizer.
Après une installation de CWA 2007 R2 derrière un Load Balancer, une post-configuration doit être faite. En résumé, il suffit d’autoriser les accès anonymes à la page /cwa/AuthMainCommandHandler.ashx.
Dans les détails, voici la procédure :
Ouvrir IIS sur les serveur CWA, et aller dans Sites, Communicator Web Access, cwa :
Avec la souris, cliquer à droite de la barre d’adresses pour voir afficher tous les fichiers du répertoire cwa et sélectionnner AuthMainCommandHandler.ashx (faire Entrée pour le sélectionner) :
Configurer les paramètres d’authentification pour avoir Anonymous Authentication = Enabled.
La connexion à CWA derrière un répartiteur de charge devrait être fonctionnelle à présent.
L’infrastructure BlackBerry dispose d’un composant permettent d’avoir la présence OCS sur les téléphones du même nom par une interconnexion avec un serveur CWA. Si cela fonctionne bien dans un environnement OCS 2007, ce n’est pas la même chose avec OCS 2007 R2. En effet, les API Ajax de CWA 2007 n’ont pas été reconduites sur CWA 2007 R2. Il est donc, de base, impossible de configurer une intégration BlackBerry dans un environnement OCS 2007 R2.
Les solutions supportées par Microsoft sont les suivantes, en fonction de différents cas de départ:
- Migration d’OCS 2007 vers OCS 2007 R2 : il suffit de conserver au moins 1 serveur CWA 2007 dans l’infrastructure migrée
- Installation d’OCS 2007 R2 pour la première fois : avant d’installer OCS 2007 R2, effectuer la préparation d’Active Directory pour OCS 2007, installer uniquement CWA 2007 et poursuivre avec l’installation d’OCS 2007 R2.
- OCS 2007 R2 est déjà installé : si la forêt et le domaine n’ont jamais été préparés pour OCS 2007 (R1), il faut exécuter les opérations ForestPrep et DomainPrep d’OCS 2007 en utilisant l’interface graphique. Ensuite, il sera possible d’installer un serveur CWA 2007.
Après une installation sur Windows Server 2008, il se peut que les services OCS 2007 R2 ne démarrent pas automatiquement et ralentissent donc le processus de démarrage du serveur.
Dans certains cas, il peut être nécessaire de configurer les services OCS pour qu’ils soient dépendants du service WMI Performance Adapter (WmiApSrv).
La résolution passe par deux étapes :
- Paramétrer le service WMI Performance Adapter (WmiApSrv) pour qu’il démarre en mode Automatic
- Configurer les deux services suivants pour qu’ils dépendent de WmiApSrv :
Pour rappel, la modifications des dépendances de fait dans la base de registres, dans KHLM\SYSTEM\CurrentControlSet\Services\<Service>, où il faut ajouter une ligne contenant WmiApSrv dans le paramètre DependOnService
Ces modifications permettront aux services OCS de démarrer sans problème à chaque démarrage.
Après une installation de Communicator Web Access 2007 R2, il se peut que lors de la connexion, un message du type "Your computer clock is not set correctly".
Ce comportement est lié à Kerberos et se produit si l'URL utilisée pour accéder à CWA 2007 R2 ne correspond pas au nom du serveur CWA.
Pour résoudre ce problème, il suffit d'ajouter un SPN au compte de service CWA pour le service http. Prenons un exemple :
- Le serveur CWA a comme FQDN cwaserver.contoso.com
- Le compte de service utilisé pour CWA est CWAService du domaine CONTOSO
- Le service CWA est accéder par les utilisateur sur l'URL https://im.contoso.com
Dans ce cas, il faut ajouter le SPN http/im.contoso.com au compte de service CONTOSO\CWAService. Pour cela, il faut exécuter la commande SetSpn -A http/im.contoso.com CONTOSO\CWAService.
Il faut faire de même pour les URL as.im.contoso.com et download.im.contoso.com, donc exécuter les deux commandes suivantes:
- SetSpn -A http/as.im.contoso.com CONTOSO\CWAService
- SetSpn -A http/download.im.contoso.com CONTOSO\CWAService
Pour information, les URL as.<URL CWA> et download.<URL CWA> permettent de faire fonctionner le Desktop Sharing dans CWA.
Le temps que la réplication Active Directory soit complète et après un redémarrage de IIS sur le serveur CWA, la connexion devrait être opérationnelle.
Pour faire suite à mon billet sur la publication des Web Components pour OCS 2007, voici la version pour OCS 2007 R2.
La règle de publication des Web Components sur ISA Server doit autoriser les chemins suivants :
- /Abs/Ext/*
- /AutoUpdate/Ext/*
- /Conf/Ext/*
- /DeviceUpdateFiles_Ext/*
- /Etc/*
- /GroupExpansion/Ext/*
- /PhoneConferencing/Ext/*
- /RequestHandlerExt/*
- /Rgs/Clients/*
En fonction des fonctionnalités mises en places, il est possible de restreindre l'accès (notamment ne pas ouvrir /Rgs/Clients/*) mais cela dépend après des possibilités offertes aux utilisateurs.
Après de la mise en place d'un ou plusieurs serveurs Edge OCS 2007 R2, notamment le rôle Audio/Video Edge Server, il se peut que les utilisateurs voient apparaître dans Office Communicator un message du genre "Appel limité", et que les communications avec des utilisateurs depuis ou vers l'Internet ne fonctionnent pas.
Ce comportement est dû au format des paramètres régionaux qui, lorsqu'ils sont mis en Français par exemple, font que les chiffres contiennent des virgules et non des points. Or, le compte de service faisant fonctionner le ou les serveurs Edge a besoin d'avoir des paramètres régionaux qui imposent des chiffres avec des points et non des virgules. Etant donné que la plupart des serveurs en France sont configurés lors de l'installation avec des paramètres régionaux de type "France", inutile de faire un dessin...
Pour que le rôle Audio/Video Edge Server fonctionne, inutile de réinstaller Windows : il suffit d'ouvrir une session sur le serveur Edge en utilisant le compte de service (par défaut RTCProxyService), d'aller dans le Panneau de Configuration, Options Régionales et Linguistiques (Regional and Language Options), et de sélectionner Anglais (Etats-Unis) ou English (US). Un redémarrage plus tard, le problème devrait avoir disparu.
Dans une infrastructure où OCS 2007 R2 permet d'utiliser le client Office Communicator comme un téléphone, il se peut que de temps à autres, l'établissement de la communication audio ne soit pas instantanée lorsque l'utilisateur appelle l'extérieur (ou plus exactement effectue un appel qui passe par le Mediation Server).
Ce comportement peut se produire lorsque le Mediation Server OCS 2007 R2 est déployé sur une machine Windows Server 2008 qui a le pare-feu Windows activé (configuration par défaut). Bien qu'une exception soit créée automatiquement dans le pare-feu pendant l'installation pour autoriser le processus Mediation Server à ouvrir des ports, la particularité dite "Early Media" d'OC 2007 R2 peut avoir un effet de bord : si le client est très proche du Mediation Server, les premiers paquets UDP qu'OC envoie sont rejetés. En effet, le pare-feu Windows n'a pas le temps d'ouvrir les ports demandés par le processus Mediation Server, et refuse donc de laisser passer les premiers flux qu'OC envoie, tellement ce dernier commence tôt. Dans ce cas de figure, il se peut que l'utilisateur sur OC n'entende pas celui qu'il appelle.
Personnellement, j'ai observé ce cas lors de l'appel à une boîte vocale plutôt qu'à une "vraie" personne.
Cela dit, pour éviter ce comportement, s'il se produit, il suffit tout simplement de désactiver le pare-feu Windows sur le Mediation Server OCS 2007 R2.
OCS 2007 R2 sort officiellement aujourd'hui. Le prochains billets seront donc probablement orientés autour de ce produit.
Pour commencer, voici quelques modifications à réaliser après l'installation d'OCS 2007 R2 dans une configuration Enterprise Edition sur Windows Server 2008. Ces modifications ne sont pas à réaliser sur Windows Server 2003 ou avec OCS 2007 R2 Standard Edition.
Sur les serveurs Front End où le rôle Web Components est installé, il est nécessaire de modifier légèrement la configuration dans IIS 7.0 afin que le Web Conferencing ainsi que la mise à jour des téléphones autonomes Office Communicator Phone Edition soient fonctionnels. Sans cette modification, l'accès aux URL https://<PoolFQDN>/DeviceUpdateFiles_Int et https://<PoolFQDN>/Etc/Place/Null/FileTree affiche une erreur "500 - Internal server error". Cette erreur est due à un problème d'authentification de IIS sur les partages de fichiers où sont stockés les conférences Web ainsi que les mises à jour Office Communicator Phone Edition.
Pour les répertoires virtuels ci-dessous, il faut donc modifier les paramètres pour que le compte utilisé pour se connecter aux partages de fichiers soit RTCGuestAccessUser (ou le compte équivalent dans le cas où il aurait été nommé différemment) au lieu de "Pass-through authentication" :
- DeviceUpdateFiles_Int
- Etc/Place/Null/FileTree
Pour faire cela, il suffit d'ouvrir la fenêtre "Basic Settings" pour chacun de ces 2 répertoires virtuels dans IIS, et cliquer sur "Connect As" et d'entrer le nom et le mot de passe du compte correspondant à RTCGuestAccessUser.
Ces derniers jours, à la suite de la réinstallation de mon PC sous Windows Server 2008 (pour profiter d'Hyper-V), j'ai lancé une petite recherche sur le net pour voir si, par hasard, quelqu'un aurait trouvé une solution pour pouvoir faire fonctionner la veille et l'hibernation, puisque l'installation du rôle Hyper-V désactive ces deux fonctionnalités bien pratiques.
Et comme par hasard, j'ai trouvé quelqu'un qui propose une solution acceptable. La version originale est ici : http://markharrison.co.uk/blog/2008/09/sleep-hibernate-with-hyper-v.htm
Globalement, l'idée consiste à modifier les paramètres de démarrage d'un service nommé hvboot pour qu'il ne démarre pas automatiquement mais manuellement. Et ce qui est intéressant, c'est que tant que ce service n'est pas démarré, la veille et l'hibernation fonctionnent !
Voici donc la modifications à faire dans le registre :
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hvboot]"Start"=dword:00000003
Pour démarrer le service, tout simplement faire : net start hvboot
Et ensuite, il est possible de démarrer des machines virtuelles.
Petit inconvénient (mais qui est acceptable selon moi), c'est qu'une fois démarré, le service hvboot ne peut pas être arrêté. Il faut donc redémarrer la machine pour pouvoir à nouveau mettre en veille et hiberner.
Les clients Office Communications Server 2007 qui ne sont autres que Office Communicator 2007, Live Meeting Console 2007 ainsi que le Tanjay (le téléphone IP autonome - Office Communicator Phone Edition) accèdent au serveur OCS qui héberge le role Web Components via un reverse proxy lorsqu'ils sont connectés sur l'Internet.
Afin de sécuriser au maximum les accès (HTTPS est le minimum), il est possible de configurer la règle de publication des Web Components sur ISA Server de manière à n'autoriser que les chemins suivants :
- /Abs/Ext/*
- /Conf/Ext/*
- /Etc/*
- /GroupExpansion/Ext/*
- /RequestHandler/ucdevice.aspx
Le dernier élément permet aux téléphones Office Communicator Phone Edition se vérifier si des mises à jour sont disponibles. Donc si le service Device Update Service n'est pas installé, ce dernier élément n'est pas nécessaire. Bien sûr, dans le cas où il serait installé, il faut aussi penser à publier l'URL permettant d'accéder au site WSS 3.0 contenant les mises à jour...
La fiche technique suivant référence les autorités de certification publiques qui ont travaillé étroitement avec Microsoft de manière à proposer aux sociétés des certificats conformes aux besoin d'Exchange Server 2007 et / ou Office Communications Server 2007 : http://support.microsoft.com/kb/929395/en-us
Globalement, le besoin supplémentaire par rapport à un certificat serveur classique est le support du champ Subject Alternate Name dans le certificat.
Il est aussi intéressant de noter que d'autres autorités de certifications que celles listées dans la fiche technique peuvent proposer les bons certificats.
