PI Services

Le blog des collaborateurs de PI Services

OCS 2007 R2 – Erreurs lors de la publication de CWA à travers IAG/UAG

Symptôme

Suite à la publication de l’interface Communicator Web Access à travers un équipement de type “reverse proxy” (ISA/TMG ou IAG/UAG), l’erreur suivante se produit de manière aléatoire (environ 1 fois sur 3) :

Cannot sign in because your computer clock is not set correctly or your account is invalid

Voici l’intitulé exact de l’erreur :

Cannot sign in because your computer clock is not set correctly or your account is invalid.(Error code: 0-1-492)

Explication

Cette erreur est un “classique” sur CWA. Elle se produit souvent lorsque l’URL utilisé pour accéder au service Web ne correspond pas au certificat positionné dans IIS ou bien encore aux URL d’accès publiées durant la configuration OCS (étape 4 de l’assistant d’installation du rôle CWA).

image

Cette erreur peut également se produire lorsque les SPN du compte ordinateur sont mal configurés et ne contiennent pas le SPN correspondant à l’URL publiée. Pour cela le SPN manquant peut être rajouté en suivant la procédure suivante :

    Dans ce cas précis, la bonne URL est utilisée lors de l’accès et les SPN du serveur hébergeant CWA sont correctement configuré ! De plus l’erreur ne se produit pas systématiquement mais de manière aléatoire, et ce, uniquement à travers un équipement de type “reverse proxy” (comprendre l’accès à CWA depuis le LAN fonctionne systématiquement et sans aucune erreur) !

Résolution

Après quelques recherches sur le Web, je suis tombé sur le billet suivant qui propose d’activer l’authentification de type Anonyme sur l’une des pages du site CWA (page AuthMainCommandHandler.ashx).

http://www.tincupsandstring.com/2009/03/31/cwa-error-code-0-1-492/

Dans notre cas, cette manipulation a totalement corrigé le problème rencontré avec les publications de CWA à travers Unified Access Gateway (UAG) et Intelligent Application Gateway (IAG).

Configurer la page AuthMainCommandHandler.ashx

Configurer la page AuthMainCommandHandler.ashx

Remarque : A priori ce problème peut également être rencontré lors de la mise en place d’un load balancing matériel (HLB) sur le site CWA (cf. Blog Technet de Stefan Plizga).

OCS 2007 R2 – Appliquer l’ensemble des mises à jour disponibles sur un serveur OCS

Depuis sa sortie en 2009, de nombreuses mises à jour sont régulièrement publiées pour OCS 2007 R2.

L’application de l’ensemble de ces patchs peut sembler complexe à première vue. En effet Microsoft ne développe pas de correctifs  “globaux” contrairement à Exchange ou TMG mais plutôt des correctifs ciblés sur chaque composant d’OCS :

  • Application Host
  • Application Sharing Server
  • Administration Tools
  • Audio/Video Confering
  • Core Components
  • Communicator Web Access
  • Conferencing Attendant
  • Conferencing Announcement Service
  • Monitoring Server
  • Mediation Sever
  • Outside Voice Control
  • Response Group Service
  • Standard / Enterprise edition Server
  • Standard / Enterprise edition Back-End
  • Unified Communications Managed API 2.0 Core Redist 64-bit
  • Web Conferencing Server
  • Web Components Server

En fonction des rôles installés sur chaque serveur OCS certains packages accepteront de s’installer et d’autres non !

Afin de simplifier l’application de l’ensemble des mises à jour sur un serveur OCS 2007 R2, Microsoft met à disposition deux outils très pratiques :

L’outil détecte les rôles installé sur le serveur local, télécharge les mises à jour associées et enfin les installe toute !

Pour mettre à jour entièrement un serveur OCS 2007 R2 nouvellement installé, les deux fichiers suivants doivent être téléchargés :

  • ServerUpdateInstaller.exe
  • OCS2009-DBUpgrade.msi
    Mises à jour OCS 2007 R2

Voici la fenêtre affichée par l’outil de déploiement des mises à jour sur un serveur Front-End OCS 2007 R2. Il suffit de cliquer sur le bouton Install Updates pour déclencher l’installation de l’ensemble des mises à jour.

Mises à jour OCS 2007 R2

Après une quinzaine de minutes (temps d’installation de l’ensemble des mises à jour), l’outil propose de redémarrer le serveur.

Mises à jour OCS 2007 R2

Suite au redémarrage du serveur il est probable que le service principal d’OCS (service Front-End) ne démarre pas.

En effet certaines mises à jour nécessitent une mise à jour de la base de données RTC associée à OCS 2007 R2.

Pour cela le fichier MSI précédemment téléchargé doit être exécuté avec le paramètre POOLNAME=<FQDN de votre pool de serveurs Front-End>.

A l’issue de ces manipulations, le serveur OCS 2007 R2 est 100% à jour.

OCS 2007 R2 – Erreur 0xC3EC78D8 lors de l’ajout d’un serveur à un pool existant

Symptôme

Lors de l’ajout d’un serveur OCS 2007 R2 au sein d’un pool de serveur front-end, l’erreur suivante peut se produire :

[0xC3EC78D8] Failed to read the Office Communications Server version information. This can happen if the computer clock is not set to correct date and time

Erreur 0xC3EC78D8 sur OCS 2007 R2

De plus l’erreur suivante peut également apparaître dans le journal d’évènements Applications (y compris si vous utilisez des sources auxquelles est associée une licence valide) :

The evaluation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from the evaluation version to the full released version of the product.

Explication

Contrairement aux intitulés qui sont parfois trompeurs, ces erreurs ne sont pas dues à un problème de synchronisation d’horloge ni de” version” mais tout simplement à une mise à jour de Windows (bulletin de sécurité MS09-056).

Résolution

Pour résoudre ce problème et pouvoir ajouter avec succès le serveur au sein du pool OCS existant, deux alternatives sont possibles :

  • Désinstaller la mise à jour de sécurité KB974571
  • Utiliser l’outil OCSASNFix.exe

L’outil OCSASNFix est disponible à l’adresse suivante :

http://support.microsoft.com/kb/974571/en-us

OCS 2007 R2 – Echec des connexions TLS sous Windows Server 2008 R2

Symptôme

Suite au déploiement d’une architecture OCS 2007 R2 composée de plusieurs serveurs (typiquement un serveur front-end déployé dans le réseau local associé à un serveur Edge situé en DMZ), les erreurs suivantes peuvent se produire si l’un des serveurs ou les deux exécutent Windows Server 2008 R2 :

Event ID : 14428, Source : OCS Protocol Stack

Event ID : 14428, Source : OCS Protocol Stack

Voici le détail de chacune des deux erreurs :

Log Name: Office Communications Server
Source: OCS Protocol Stack
Date: 23/12/2010 00:53:43
Event ID: 14428
Task Category: (1001)
Level: Error
Keywords:  Classic
User:  N/A
Computer: <FQDN du serveur OCS source>
Description:
TLS outgoing connection failures. Over the past 15 minutes Office Communications Server has experienced TLS outgoing connection failures 122 time(s). The error code of the last failure is 0x80004005 (Unspecified error) while trying to connect to the host “<FQDN du serveur OCS de destination>”.

 

Log Name: Office Communications Server
Source: OCS Protocol Stack
Date: 23/12/2010 00:46:08
Event ID: 14502
Task Category: (1001)
Level: Error
Keywords: Classic
User: N/A
Computer: <FQDN du serveur OCS source>
Description:
A significant number of connection failures have occurred with remote server <FQDN du serveur OCS de destination>”. IP <Adresse IP du serveur OCS de destination>”. There have been 60 failures in the last 7 minutes. There have been a total of 60 failures.  The specific failure types and their counts are identified below.

Instance count   - Failure Type
60                
80004005 

 

Explication

Ces erreurs sont dues à un problème “connus” avec OCS 2007 R2 et Windows Server 2008 R2 autour de la fonction InitializeSecurityContext de la couche TLS.

Ces erreurs empêchent toute communication TLS entre les serveurs et entraînent donc des disfonctionnement au sein d’OCS (le protocole SIPs étant utilisé par défaut).

Résolution

Pour résoudre ces problèmes, il faut installer un correctif sur l’ensemble des serveurs OCS 2007 R2. Ce correctif est disponible sur demande à l’adresse suivante :

Suite à l’installation, les serveurs doivent être redémarrés.

OCS2007R2 – Migrer les bases de données d’OCS vers un nouveau serveur SQL

Dans le cadre d’une migration depuis un “ancien” serveur SQL 2005 vers un nouveau serveur sous SQL 2008 SP1, j’ai été amené à déplacer les bases de données associées à un pool OCS 2007 R2.

Ce billet décrit la procédure à suivre pour réaliser cette opération.

La première étape consiste à arrêter tous les services OCS sur le ou les serveurs frontaux composant le pool.

image

Ensuite, il faut se connecter au serveur SQL et mettre hors ligne l’intégralité des bases de données liées à OCS 2007 R2.

image

N.B. : Il est également possible d’utiliser la fonction “Detach…”, voire d’effectuer une sauvegarde des bases.

image

Les fichiers de bases de données (MDF) ainsi que les journaux de transaction (LDF) doivent être copiés sur le serveur SQL de destination dans les répertoires appropriés.

Il est ensuite possible de rattacher les bases de données OCS sur le serveur SQL de destination à l’aide de la console SQL Server Management Studio. Pour cela il faut se connecter à l’instance adaptée, faire un clic droit sur “Databases” puis sélectionner “Attach…”.

image

Dans la fenêtre permettant de rattacher une base SQL, il faut cliquer sur “Add”, puis sélectionner le fichier MDF nouvellement copié.

Attention : Il est possible que le fichier LDF ne soit pas localisé automatiquement (notamment si l’emplacement de stockage a changé par rapport au serveur SQL d’origine). Dans ce cas un message “Not Found” s’affiche en face du fichier LDF et le chemin doit être corrigé manuellement.

image

Cette opération doit être répétée pour chacune des bases de données OCS 2007 R2.

Le script suivant doit ensuite être exécuté dans la console SQL Server Management Studio afin de repositionner les autorisations nécessaires sur les groupes d’administration OCS (<domain> doit être remplacé par le nom NetBIOS de votre domaine Active Directory) :

CREATE LOGIN [<domain>\RTCArchivingUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;
CREATE LOGIN [<domain>\RTCComponentUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;
CREATE LOGIN [<domain>\RTCHSUniversalServices] FROM WINDOWS WITH DEFAULT_DATABASE=master;
CREATE LOGIN [<domain>\RTCUniversalReadOnlyAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;
CREATE LOGIN [<domain>\RTCUniversalServerAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;
CREATE LOGIN [<domain>\RTCUniversalUserAdmins] FROM WINDOWS WITH DEFAULT_DATABASE=master;
EXEC sp_dboption 'rtc', 'db chaining', TRUE EXEC sp_dboption 'rtcdyn', 'db chaining', TRUE

Remarque : Ce script est fournit par Marc Stecy.

Une fois le script exécuté, vous pourrez vérifier la présence des groupes OCS dans la section Security / Logins de la console SQL.

image

Enfin, la dernière étape consiste à exécuter la commande suivante sur le serveur OCS (le but de cette commande est de reconfigurer le pool OCS pour pointer vers le nouveau serveur SQL) :

lcscmd /forest /action:updatepoolbackend /poolname:mypool /poolbe:mysqlserver\rtc

 

Remarque : “mypool” doit être remplacé par le nom NetBIOS du pool et mysqlserver\rtc représente la nouvelle instance SQL Server (si vous utilisez l’instance par défaut alors il suffit de préciser le nom du serveur).

A l’issue de cette étape vous pouvez valider la bonne modification du pool en affichant la valeur de l’attribut msRTCSIP-BackEndServer à l’aide d’ADSIEdit.

image 

Une fois ce point validé, la migration est terminée et les services OCS peuvent être redémarrés !