OCS (R2) et le DNS... (partie 1: la théorie)

Introduction

Comme vous le savez tous, OCS 2007 et OCS 2007 R2 capitalisent sur un système DNS bien provisionné afin de permettre aux clients de pouvoir se connecter automatiquement, en fonction de l'adresse SIP de l'utilisateur.

C'est particulièrement pratique pour plusieurs raisons:

• Effort d'administration réduit
• Perception de l'utilisateur, qui apprécie de ne rien avoir à faire (ou presque :))
• Maniabilité de l'infrastructure

Certes, il est possible de configurer les clients par stratégie de groupe (GPO) afin de reproduire quelque chose de similaire, mais lorsque des changements doivent s'appliquer, cela se complique car les stratégies ne s'appliquent pas immédiatement (utilisateurs connectés en attente de rafraîchissement, utilisateurs mobiles), voire pas du tout (clients hors du domaine, ou externes).

Alors, quels sont les enregistrements DNS qu'un client OC va rechercher lors de son démarrage ?

Il s'agit de ceux-ci:

• _sipinternaltls._tcp.domaine.com
• _sipinternal._tcp.domaine.com
• _sip._tls.domaine.com
• _sip._tcp.domaine.com
• sip.domaine.com

Les quatre premiers enregistrements doivent être de type "SRV" (Service Locator), sauf si vous avez changé les ports part défaut, les versions "TLS" doivent pointer vers le port 5061 et les autres vers le port 5060. Le dernier est un enregistrement de type "A" (hôte IPv4).

Je rappelle qu'OCS 2007 et OCS 2007 R2 sont configurés par défaut pour utiliser le port 5061 (SIP sur TLS), il n'est donc pas nécessaire de créer les enregistrements "_sipinternal._tcp" et "_sip._tcp" si vous n'avez pas configuré OCS pour écouter sur ce port. Je reviendrai plus tard sur l'accès distant au travers d'un serveur Edge.

Le problème

Le DNS c'est bien, mais voilà... c'est parfois un casse-tête car tout le monde n'a pas le moyen d'utiliser ce que l'on appelle communément un "split DNS".

En effet, imaginez que votre domaine SIP soit "uc-lab.com": la configuration idéale qu'il corresponde au domaine SMTP utilisé par la messagerie, mais aussi à tout ce qui est visible de l'extérieur... Par exemple www.uc-lab.com.

Dans ce cas, que se passe-t-il ? Afin que la découverte auomatique fonctionne, vous configurez au moins ceci:

• Sur vos serveurs DNS interne, vous créez une zone DNS nommée "uc-lab.com"
• Un enregistrement A nommé "sip.uc-lab.com" (notez qu'il est possible d'utiliser autre chose que "sip.domaine.com", l'avantage de cet enregistrement est cependant d'autoriser la configuration automatique si le client ne sait pas faire de requête SRV ou simplement si vous n'avez pas de serveur DNS capable de gérer les SRV -- Ok ok, de nos jours c'est très marginal =°))
• Un enregistrement SRV "_sipinternaltls._tcp.uc-lab.com" pointant vers "sip.uc-lab.com"

Un fois tout ce petit monde en place, vous confirmez que vous arrivez à vous connecter à OCS, mais se pose alors un autre problème... Lorsque vous voulez accéder au site www.uc-lab.com depuis votre réseau interne, vous vous faites insulter par votre navigateur Web préféré... Aïe... normal puisque votre DNS interne gère désormais la zone "uc-lab.com", si vous utilisiez un redirecteur DNS ou les DNS racines les requêtes vers ceux-ci cessent et donc c'est à votre ou vos serveur(s) interne(s) de répondre. Vu qu'aucun enregistrement nommé "www" n'existe, normal que la recherche de www.uc-lab.com échoue.

Il vous reste alors deux options qui semble "triviales":

1. Créer un enregistrement A pour www.uc-lab.com - Ok, pourquoi pas, mais cela oblige à une double gestion, ce qui n'est pas toujours une synécure. Imaginez la catastrophe si vous avez des centaines d'enregistrements à gérer sur vos DNS externes !!!
2. Ne pas utiliser de split DNS, ce qui revient donc à créer ces enregistrements sur une zone DNS externe (sur un DNS public) et de la mettre à disposition en interne (par réplication ou redirection) - Ce n'est pas toujours faisable, et cela pose un autre problème: cela oblige à publier une adresse IP interne sur une zone DNS publique... Ce n'est pas élégant, et pire, un client externe essayera de s'y connecter puisqu'il pourra la résoudre, puis passera à l'enregistrement suivant qui, si tout va bien, sera celui d'un serveur Edge et donc lui permettra de se connecter. Cependant, cela ralentit le processus de connexion.

Ces solutions sont donc à éviter, autant que faire-ce-peut, car voici _LA_ solution.

La (meilleure?) solution

Il suffit de rappeller comment fonctionne le DNS. Basiquement le caractère "." est le séparateur de labels dans le nom complet qualifié de l'enregistrement recherché. Par exemple, dans "sip.uc-lab.com" "sip" est le nom d'hôte (aussi appellé nom relatif), "uc-lab" et "com" sont des labels arbitraires, même si "com" est aussi une zone racine sur Internet (on appelle aussi ce label "extension").

Aussi, peut importe la façon dont ces enregistrements sont stockés par le serveur DNS, ce qui importe, c'est qu'ils puissent être résolus.

Petit exemple, imaginez un nom complet qualifié "serveur.dom1.aa.domaine.com", disons qu'il est de type "A". Quelles sont alors les façons possibles de déclarer cet enregistrements auprès d'un DNS. Il en existe en fait au moins cinq:

1. Créer une zone "com" puis un enregistrement relatif "serveur.dom1.aa.domaine"
2. Créer une zone "domaine.com" puis un enregistrement relatif "serveur.dom1.aa"
3. Créer une zone "aa.domaine.com" puis un enregistrement relatif "serveur.dom1"
4. Créer une zone "dom1.aa.domaine.com" puis un enregistrement relatif "serveur"
5. Créer une zone "serveur.dom1.aa.domaine.com" puis en enregistrement relatif "" (nom vide)

L'option #1 est à éviter (à moins de vouloir bloquer *.com :)), les options #2/3/4 sont des classiques, et l'option #5 semble "juste bizarre". C'est pourtant cette façon de déclarer les enregistrements DNS qui va changer la donne et résoudre tous les problèmes... ! :)

Typiquement sur un DNS de type "bind" (ex: sur Unix), cela revient à jouer avec le mot-clef "$ORIGIN" (qui est exposé dans un DNS Windows si vous n'utilisez pas Active Directory pour stocker les informations DNS, mais plutôt un fichier "nomdezone.dns").

Aussi, en reprenant mon exemple avec le domaine "uc-lab.com", il suffit de créer les zones et enregistrements suivants:

• Zone: "_tcp.uc-lab.com" ==> Enregistrement SRV relatif nommé "_sipinternaltls" pointant vers "sip.uc-lab.com"
• Zone: "sip.uc-lab.com" ==> Enregistrement A relatif non nommé (chaine vide)

Et voilà, un client DNS n'y verra que du feu et cela permettra de conserver des redirecteurs ou l'utilisation de serveurs DNS racines pour résoudre

Autres applications

Pour OCS, n'oubliez pas si votre déploiement comporte des clients de type Communicator Phone Edition (CPE), ou si vous utilisez Communicator Web Access (CWA), vous devrez créer des enregistrements supplémentaires (les zones sont en gras):

Pour CPE:

• ucupdates.domaine.com (A)
• ucupdates-r2.domaine.com (A)
• _ntp._udp.domaine.com (SRV relatif "_ntp" vers un sevrveur NTP interne)

Pour CWA (optionnel/pas toujours applicable, mais personnellement j'aime avoir le même nom de serveur CWA en interne et en externe):

• cwa.domaine.com (A)
• as.cwa.domaine.com (CNAME relatif "as" vers l'enregistrement A racine dans cwa.domaine.com)
• download.cwa.domaine.com (CNAME relatif "download" vers l'enregistrement A racine dans cwa.domaine.com)

En bonus, si vous avez Exchange 2007 + Outlook 2007 et que vous souhaitez utiliser Outlook Anywhere en interne (ex: clients hors de la forêt AD, mais se connectant depuis les réseaux internes):

• autodiscover.domaine.com (A représentant l'IP de votre serveur CAS principal ou du load-balancer si vous avez plusieurs CAS)
• et/ou _autodiscover._tcp.domaine.com (SRV pointant vers le port 443 et le nom d'hôte de votre CAS ou du load-balancer)

Et en externe... ?

Le même principe peut s'appliquer, même si cela ne devrait pas être nécessaire puisque tout peut être géré au sein de la même zone. La différence majeure se situe au niveau des enregistrements SRV, en effet, on préfèrera déclarer les enregistrements suivants:

• sip.domaine.com (A représentant l'IP du rôle Access Edge du serveur Edge (ou du load-balancer dans le cas d'un pool de serveurs Edge))
• _sip._tls.domaine.com (SRV pointant vers "sip.domaine.com" sur le port 443 (port par défaut pour l'accès distant des clients OCS au travers du Edge)
• Et si la fédération est utilisée: _sipfederationtls._tcp.domaine.com (SRV vers "sip.domaine.com" sur le port 5061 si le même serveur Edge est utilisé pour la fédération)

Conclusion

Malgré la longueur ce cet article, le principe est somme toute assez simple, nous verrons dans le prochain article comment mettre tout ceci en oeuvre sur un DNS Windows, avec la console d'administration DNS et l'utilitaire dnscmd.exe...

OCS 2007 R2 / Communicator 2007 R2 - Correctif pour les versions d'évaluation

Décidément, nos amis de Microsoft ont un souci avec le 13 Juin (rappellez-vous le problème de l'outil ABSConfig...)

Suite à un petit bogue, les personnes ayant installé une version d'évaluation d'OCS 2007 R2 et/ou de MOC 2007 R2 se retrouvent en carafe depuis avant-hier.

Pour corriger le problème, il suffit d'installer ces deux correctifs:

• Sur le serveur (si le serveur est en Eval): http://www.microsoft.com/downloads/details.aspx?FamilyID=b3b02475-150c-41fa-844a-c10a517040f4&displaylang=en
• Sur les clients (si les clients sont en Eval): http://www.microsoft.com/downloads/details.aspx?FamilyID=515d6dba-4c6a-48bb-a06a-d99c5742676d&displaylang=en

Ces correctifs n'apportent rien de plus part rapport aux mises à jour d'Avril (OCS R2 build .9) et de Mai (MOC 2007 R2 build .22). Il faudra encore attendre quelques semaines pour le QFE2... :)

OCS R2, SQL 2008 et WMI

Durant mes expériementations sur mon "environnement de jeu", j'ai voulu aller trifouiller la configuration de mon nouveau Pool OCS R2 tout fraîchement installé avec un serveur SQL 2008 en tant que serveur dorsal, et s'exécutant sur Win20008 x64 (mes frontaux étant aussi installés sur Win2008 x64).

Bref... le moyen le plus simple étant d'utiliser wbemtest pour aller bidouiller la configuration, je décide de faire "comme d'habitude":

1. Se connecter à root\cimv2 (pratique, sur Win2008 c'est le contexte de connexion par défaut)
2. Aller dans "Query" et entrer la requête en langage WQL (WMI Query Language), comme par exemple "select * from msft_sipaddressbooksetting where backend = 'sv-sql'"
3. Et là, le drame... Au lieu de fonctionner et de me retourner l'instance de la classe correspondante, je me fais insulter avec une erreur inconnue... Késako ?

Je vérifie alors quelques éléments:

• Mon pool est configuré pour se connecter à "sv-sql\OCSR2"
• Mes frontaux fonctionnent parfaitement bien
• Mon serveur SQL a les exceptions correctes sur le pare-feux Windows: les services SQL et le service SQLBrowser sont tous mis en exclusion
• Mon service SQL pour l'instance OCSR2 est bien configuré pour TCP/IP et là... Je me rappelle/réalise que SQL 2008 est joueur... Pour une instance nommée, un port aléatoire est choisi, contrairement à l'instance par défaut qui s'exécute sur le port TCP 1433 !

Je prends alors mon Netmon, et lance une trace réseau en réessayant un Wbemtest, afin de voir ce qui se trame (admirez le jeu de mots =°)) derrière...

Je découvre alors que la requête WMI déclence une connexion SQL sur le port... 1433 ! Damned...

J'arrête donc proprement les services sur mes frontaux, change le port d'écoute de mon instance SQL en 1433 et redémarre mon instance. Une validation avec un 'netstat -an find /I 1433' confirme que le port est ouvert en écoute...

Après un redémarrage de mes services frontaux, je tente à nouveau ma requête WQL, et elle fonctionne !

Une autre technique, beaucoup plus simple et d'utiliser le nom complet de l'instance SQL, par exemple select * from msft_sipaddressbooksetting where backend = 'sv-sql\\OCSR2' (notez le double backslash, un grand classique :))

Moralité: Normalement, vous n'avez pas besoin de trifouiller la base SQL avec WMI (je rappelle tout de même que c'est l'interface qui est supportée par Microsoft pour configurer OCS/OCS R2, et que modifier directement la base SQL n'est pas supporté). Dans certains cas, cela nécessaire, comme par exemple activer la QoS, changer les URLs de publication des services Web, ou juste parce qu'il faut changer une valeur bien particulière (en général pour une raison tout autant particulière =)).