Nouvelles mises à jour OCS 2007 R2 / MOC 2007 R2 [...]

Microsoft a publié récemment un ensemble de mises à jour pour OCS 2007 R2 et MOC 2007 R2. Côté serveur, l'ensemble des mises à jour reprend quelques mises à jour précédentes et mettent à niveau certaines au build ".37".

Un package MSI est aussi fourni permettant la mise à jour de la base de données des Pools OCS 2007 R2 afin de corriger un problème avec la fonctionnalité "My meeting" (bien que ce problème soit rare, il peut vite devenir embêtant). Bien évidemment, cette mise à jour de la base est recommandée bien qu'elle ne soit pas requise pour l'application des correctifs.

Communicator 2007 R2 passe aussi en version ".37". Des mises à jours Live Meeting 2007 et Add-in Outlook sont en route.

Au passage, il est à noter une mise à jour des documentations OCS 2007 R2 (en particulier l'excellente documentation au format CHM, qui passe de 9 Mo à environ 12 Mo :)).

• Liste maîtresse des correctifs OCS 2007 R2 (en cours de mise à jour): http://support.microsoft.com/?kbid=968802
• Mise à jour OCS 2007 R2: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4
• Mise à jour Communicator 2007 R2: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=515d6dba-4c6a-48bb-a06a-d99c5742676d
• Ensemble de documentations OCS 2007 R2: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=e9f86f96-aa09-4dca-9088-f64b4f01c703#filelist

N'oubliez pas de toujours tester l'application des mises à jour dans un environnement d'intégration et de revalider que l'intégralité des fonctionnalités utilisées fonctionne toujours après application.

Bonnes mises à jour :)

OCS 2007 R2 et le pare-feu intégré à Windows Server 2008

De mon avis personnel, et d'un point de vue général, c'est une erreur de désactiver le pare-feu intégré à Windows Server 2008...

Au sujet d'OCS 2007 R2 et Windows Server 2008, il est inutile de désactiver le pare-feu Windows pour l'installation d'un serveur OCS 2007 R2, quelque soit le rôle, car les exceptions seront positionnées automatiquement lors de l'installation. Fait intéressant d'ailleurs, puisqu'une personne de mon entourage avait désactivé le pare-feu en pensant bien faire... Grosse erreur, car si le pare-feu est désactivé, les exceptions ne sont pas positionnées (pourtant c'est écrit dans la docs OCS 2007 R2 ^^). Lorsqu'il a réactivé le pare-feu, badaboum, plus rien ne fonctionnait.

Sur le serveur dorsal SQL, il faudra positionner les exceptions manuellement pour le service SQL Browser et le service correspondant à l'instance SQL du Pool, cela est requit pour créer les bases du Pool à distance (depuis un frontal pour les bases d'un Pool Enterprise, ou depuis les serveurs d'Archivage ou de Monitoring lors de leur installation, c'est beaucoup plus simple...)

Jusque là tout va bien, et tout fonctionne... Jusqu'au moment où un administrateur vous remonte qu'il n'arrive pas à utiliser la console d'administration OCS 2007 R2 pour arrêter/démarrer un service depuis sa station, ou configurer l'archivage ou le monitoring...

En fait, il suffit de simplement autoriser quelques exceptions, et le problème est résolu:

1. Activer le "ping" -- permet d'éviter des lenteurs lors de la connexion au serveur depuis la console

netsh advfirewall firewall set rule name="File and Printer Sharing (Echo Request - ICMPv4-In)" new enable=yes
netsh advfirewall firewall set rule name="File and Printer Sharing (Echo Request - ICMPv6-In)" new enable=yes

2. Activer l'administration distante -- permet d'accéder aux fonctions d'administration à distance et à la gestion des services

netsh advfirewall firewall set rule group="Remote Administration" new enable=yes
netsh advfirewall firewall set rule group="Remote Service Management" new enable=yes

Voilà, le tour est joué, vous pouvez désormais pleinement administrer vos serveurs OCS 2007 R2 tournant sur Windows Server 2008 sans déscendre complètement le pare-feu Windows!

OCS (R2) et le DNS... (partie 2: la pratique)

Voici la seconde partie de l'article "OCS (R2) et le DNS" (et vous... :))

Rappel: Dans la première partie, j'expliquais pourquoi l'utilisation d'un domaine SIP correspondant à un domaine public pouvait poser problème, en particulier lorsque celui-ci correspond à une zone DNS publique contenant des enregistrements qui doivent idéalement être résolus depuis les réseaux internes d'une société, et bien sûr depuis l'extérieur.

Une méthode classique est l'utilisation d'un "split DNS", à savoir la présence d'une zone DNS correspondant au domaine SIP sur les serveurs internes et externes, chacune étant finalement maintenue indépendament l'une de l'autre. Or, cette solution, bien que parfaitement gérable dans de petits environnements, peut s'avérer très complexe lorsque beaucoup de domaines et d'enregistrement DNS sont concernés.

Afin de simplifier tout ça, je proposais donc d'utiliser un split DNS afin de créer des zones correspondantes au premier sous-niveau du domaine SIP, et non au niveau du domaine SIP lui-même.

Par exemple, une zone "sip.domaine.com" et une zone "_tcp.domaine.com", chacune contenant respectivement un enregistrement "A" racine, et un enregistrement "SRV" relatif nommé "_sipinternaltls".

Aujourd'hui, nous allons voir deux méthodes afin de créer ces enregistrements. Imaginons que je souhaite ajouter un domaine SIP nommé "unifiees.fr" et supporter la découverte automatique par mes clients en utilisant cette technique.

Méthode 1: Interface de gestion DNS Windows

Je passe les détails de la création de zone... Pour ce type de besoin en interne, mon choix s'oriente en général vers une zone intégrée à l'AD (mais sans enregistrement dynamique) et se répliquant sur tous les serveurs DNS de la forêt. Bien sûr, rien n'empêche d'utiliser un fédérateur DNS interne... plutôt qu'un DNS intégré AD.

Commençons par l'enregistrement SRV: premier point sautant au yeux, lorsque l'on veut créer un enregistrement SRV dans la zone "_tcp.unifiees.fr", l'interface nous propose de renseigner ceci:

• Service
• Protocole
• Priorité
• Poids
• Hôte cible
  

Et là, le premier reflexe est de se dire: "Mais si j'entre Service="_sipinternaltls et Protocole="_tcp", mon enregistrement SRV résultant sera... "_sipinternaltls._tcp._tcp.unifiees.fr" !!!

Et oui... mais non... Par un quelconque miracle, l'outil de gestion DNS établit que "_tcp" fait déjà partie du nom complet qualifié de l'enregistrement à créer, et zappe le double "_tcp". S'agit-il d'un bug ou d'un fait-exprès des équipes Microsoft ? Difficile à dire...

Quoiqu'il en soit, l'enregistrement créé est bien "_sipinternaltls._tcp.unifiees.fr". Qu'il s'agisse du DNS Windows 2003 ou Windows 2008, le comportement est identique.


Voici donc un moyen ultra-simple de créer l'enregistrement SRV, pratique et rapide dès lors que l'on a fait absraction du côté intattendu de la chose.

Reste ensuite à créer l'enregistrement "A" correspondant au nom d'hôte mentionné dans le SRV. Je rappelle qu'avec OCS R2, la vérification stricte du nom d'hôte s'applique par défaut, il est donc recommandé d'utiliser un nom d'hôte se terminant par ".nomdedomaine.ext" (ici: .unifiees.fr). Bien sûr, ce nom d'hôte doit être présent dans les noms alternatifs du certificat utilisé par votre Pool (qu'il s'agit d'un Pool classique ou d'un Pool utilisé comme Director).

Méthode 2: Utilisation de la commande DNSCMD.EXE

Cette méthode est moins triviale, mais beaucoup plus pratique afin d'éviter une hypothétique confusion de la part de vos administrateurs, ou tout simplement cette question récurrente: "Euh... t'es sûr que ta procédure est correcte parce que là c'est bizarre ça va faire un double '_tcp' ?" :)

Elle permet surtout d'industrialiser la création de zones et des enregistrements DNS lorsqu'une implémentation d'OCS 2007 (R2) dessert beaucoup de domaines. En bonus, elle permet de gérer la durée de vie en cache des enregistrements (TTL), ce qui peut s'avérer utile lors d'un plan de recouvrement de désastre (DRP).

Création de la zone (ici: intégrée à l'AD et se répliquant sur tous les DNS de la forêt)
dnscmd.exe serveurdns /ZoneAdd zonedns /DsPrimary /DP /forest/domain/legacy

Ce qui nous donne:

• dnscmd.exe sv-dc01 /ZoneAdd _tcp.unifiees.fr /DsPrimary /DP /forest
• puis dnscmd.exe sv-dc01 /ZoneAdd sip.unifiees.fr /DsPrimary /DP /forest

Création des enregistrements DNS
dnscmd.exe serveurdns /RecordAdd zonedns nomrelatif type donnes

Note: Dans le cas particulier d'un nom d'hôte racine à la zone, le nom relatif devra être ".".

Ce qui nous donne:

• dnscmd.exe sv-dc01 /RecordAdd "_tcp.unifiees.fr" "_sipinternaltls" SRV 0 0 5061 "sip.unifiees.fr."
• puis dnscmd.exe sv-dc01 /RecordAdd "sip.unifiees.fr" "." A "192.168.100.30"

Conclusion

Vous avez maintenant les clefs pour gérer votre DNS au mieux avec OCS 2007/R2. Bien sûr, il faudra généraliser le concept aux cas suivants:

• Enregistrement SRV pour les clients OCS Phone Edition (aka CPE) (_ntp._udp.domaine.com)
• Enregistrement SRV sur un DNS externe, pour les clients externes (_sip._tls.domaine.com)
• Enregistrement SRV sur un DNS externe, pour la fédération (_sipfederationtls._tcp.domaine.com)
• Enregistrements CWA (A pour cwa.domaine.com, CNAME pour as.cwa.domaine.com et download.cwa.domaine.com)
• Et les autres... comme ceux utilisés par Exchange par exemple (SRV et/ou A pour l'Autodiscover) ou pour les mises à jours CPE (updates.domaine.com, updates-r2.domaine.com)
  

Quelle que soit la méthode que vous préférez, n'oubliez jamais de vérifier que vos zones et enregistrements sont créés correctement...

• Dans votre console de gestion DNS
• Avec la commande nslookup, idéalement depuis un poste client
• Et lorsque vos serveurs sont opérationnels, avec un client Communicator tout simplement

Amusez-vous bien =°)