L'équipe Unified Communications c'est 20 consultants experts sur les technologies Exchange, Lync et Office 365. Les consultants de Microsoft Services France proposent à la communauté IT Française de partager sur ce blog leurs expériences.
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.
-- Stefan Plizga
Bonjour,
Ceux d'entre vous qui ont écrit des scripts PowerShell qui utilisent tour à tour des Cmd-Lets de type get-mailbox et des requêtes LDAP .Net (new-object system.directoryservices.directorysearcher) ont certainement été confronté à ce problème : les cmd-lets utilisent un Global Catalog pour effectuer les requêtes et les requêtes LDAP ou ADSI "pures" peuvent en utiliser un autre, ce qui rends le resultat inconsistent.
Evan Dodds a publié sur son blog un excellent "tip" à ce sujet : La variable automatique : $AdminSessionADSettings contient ces informations et elles peuvent être modifiées.
Cela s'appliquera évidemment à la fois au script et à la console elle même.
Guillaume Bordier
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...
Au mois d'octobre, une mise à jour OCS pour le rôle Audio/Video Conferencing Server est sortie (KB956831), en téléchargement via Microsoft Update (ou WSUS) ou via http://catalog.update.microsoft.com, en recherchant "Office Communications Server 2007".
Une fois appliquée, cette mise à jour peut entrainer le non-démarrage du service Audio/Video Conferencing Server, si le serveur n'a pas accès à l'Internet. En effet, les binaires inclus dans cette mise à jour ont été signés de la même manière que ceux inclus depuis le Rollup 2 d'Exchange Server 2007 SP1. Cela implique qu'à chaque démarrage du service Audio/Video Conferencing Server, une vérification de la signature des binaires ainsi que le téléchargement de la CRL du signataire (en l'occurence Microsoft) sont faits. Et si le serveur OCS n'a pas accès à l'Internet, le service peut ne pas démarrer.
La solution pour résoudre ce problème est décrite dans la fiche technique correspondant à la mise à jour de la KB (KB956831 - http://support.microsoft.com/kb/956831/en-us) et consiste à créer un fichier de configuration .NET pour ne pas faire de vérification de la signature des binaires.
Petite précision : il faut installer le Service Pack 1 du .NET Framework 2.0 pour que le fichier de configuration soit pris en compte. De toute manière, il est recommandé d'appliquer ce Service Pack car il inclut une mise à jour que OCS BPA vous demandera d'appliquer si ce n'est déjà fait.
Je viens de publier une dizaine de nouveaux "Tip of the Day". Vous les trouverez, avec les précédents, ici.
Ivan ROBAIN
Lors de l'installation de l'antivirus Forefront Security for Exchange Server (FSE) sur un cluster Single Copy Cluster Exchange 2007 (SCC) (http://technet.microsoft.com/en-us/library/bb892181.aspx) il peut arriver que FSE ne détecte pas le cluster et effectue une installation non cluster. Ainsi les fichiers de configuration (*.fdb) et de signatures seront stockés sur le disque local et non sur le disque partagé que vous aviez prévu d'utiliser. Si le problème persiste après plusieurs tentatives d'installation, vous pouvez appliquer la procédure suivante pour transformer l'installation en cluster-aware:
Ps: Vous êtes invité à vérifier que cette manipulation est toujours supportée!
Murat GUNYAR
Bonjour et bienvenue,
La plupart d'entre vous connaissent le sigle "MCS", non ce n'est pas le nom de code du clustering, c'est l'entité conseil de Microsoft : "Microsoft Consulting Services"
Nous sommes en France un peu plus de 160 consultants dans tous les métiers du conseil informatique, dont une trentaine personnes dédiées "UC".
UC c'est:
Notre mission est de conseiller et de mettre en place ces produits dans le respect des best-practices Microsoft ainsi que des besoins de chaque client.
Nous intervenons généralement chez les 100 plus gros clients de Microsoft France, dans le cadre de gros projets, associés ou non à des partenaires, mais aussi de temps en temps pour de l'expertise pointue de façon plus ponctuelle, ou pour des phases de "Vision & Scope" en début de projet.
Ce blog sera l'occasion pour la trentaine de consultants de s'exprimer sur les sujets qui leur tiennent à coeur, en français et en évitant si possible les annonces "pures" produits.
Vous y trouverez quelques news, mais surtout je l'espère des articles de fond qui reflètent notre expertise, ainsi que des trucs et astuces.
Enjoy,
Guillaume Bordier, Consultant UC.
Tout est dans le titre, je viens de publier 5 nouveaux tip of the day. Vous les trouverez, avec les précédents, ici.
Bonne lecture,
Ivan
Bonjour à tous,
Les sessions de l’Ignite Exchange 2010 à Londres et Düsseldorf furent l’occasion pour quelques 180 de nos clients et partenaires de découvrir tous les aspects de Exchange Server 2010.
Merci aux français qui ont fait le déplacement, j’espère qu’ils n’ont pas été déçus du voyage !
Pour ma part, ce fut une extraordinaire occasion pour échanger avec nos clients et partenaires tout en dévoilant toutes les nouveautés du produit.
Sans aucune prétention, nous (l’équipe UC de Microsoft Service France) avons organisé avec le support de notre management et l’aide des équipes marketing de Microsoft France une journée qui reviendra sur les apports principaux du produit ainsi que sur le retour d’expérience de nos clients “RDP” et “TAP” qui ont déployé en avance de phase.
C’est le 15 juin 2009, rue de l’Université pour un des derniers évènements avant le grand déménagement vers Issy.
Rendez-vous donc sur Séminaire Microsoft Exchange 2010 pour l’inscription !
A bientôt
Message personnel : un certain architecte Exchange d’un certain partenaire fournisseur de matériel a oublié quelque chose chez nos amis teutons, qu’il me contacte :)
[EDIT : le RU5 va enfin intégrer la correction de la vérification de la CRL ! great news ! : http://msexchangeteam.com/archive/2007/10/26/447356.aspx]
La plupart d’entre vous le savent déjà, passer les rollups Exchange 2007 dans des infrastructures non connectées à Internet peut poser des problèmes de lenteurs.
J’ai publié il y a quelques semaines un court article en anglais sur mon blog perso ainsi qu’un script qui permet de contourner le problème de la manière la plus “propre” possible. Ce script n’est évidemment supporté que par moi-même et Microsoft ne donne aucune garantie, mais plusieurs clients l’ont utilisé sans problème…
N’hésitez pas à poser vos questions sous forme de commentaires ou en utilisant la fiche contact du blog.
Je viens de publier 1 nouveau "Tip of the Day". Vous les trouverez, avec les précédents, ici.
Vous vous demandiez qui étaient les membres de l’équipe, les voici: http://blogs.technet.com/frmcsuc/pages/le-trombi.aspx
Voici une synthèse qui fait suite aux différents tests que j’ai pu effectuer et articles que j’ai pu lire sur la configuration de la langue des boîtes aux lettres avec Exchange 2007. En espérant que cela pourra vous aider:
http://blogs.technet.com/frmcsuc/pages/exchange2007languagesettings.aspx
Et bonne année à tous!
Murat Gunyar
[Edit du 18/12/2008: Apparemment le correctif de sécurité MS08-035 – cf. KB 953235 (http://support.microsoft.com/?id=953235) intègre des versions ultérieures des DLLs patchées, il doit donc intégrer ce correctif]
Si vous avez comme moi des clients (bien leur en prend) qui appliquent les différents fixes de sécurité sur leur infrastructure peut être serrez vous comme moi confronté à un des effets de bord introduits sur l'infrastructure Exchange par un d'entre eux (MS08-003 dans mon cas).
Dans mon cas le contexte:
Les requêtes d'administration (EMS ou EMC) sur l'infrastructure Exchange 2007 lors de la gestion des boites aux lettre remontent souvent des erreurs lorsque vous avez beaucoup d'utilisateurs (plusieurs dixaines de milliers) et/ou que vous avez des resultats triés (-sortBy).
C'est une erreur qui est décrite dans http://support.microsoft.com/?id=949876 pour laquelle vous devez obtenir le hotfix (il faut passer par le support afin d'obtenir ce fix) et l'appliquer sur les différents contrôleurs de domaine de votre infrastructure (P.S. reboot nécessaire en fin d'application du fix).
-- Philippe Maurent
Allez, un petit cocorico, c'est pas tous les jours qu'un blogs d'un petit frenchie est publié chez nos amis de Microsoft Corp!
Enjoy la langue de Shakespeare : http://msexchangeteam.com/archive/2009/01/28/450532.aspx
Nous avons tous été confrontés au pire cauchemar du consultant ou de l’administrateur de messagerie : La migration avec coexistence.
Nous allons aborder lors de cette (courte) série d’articles, les deux points clés d’une migration Exchange :
· La conservation de la « repliabilité », la faculté de répondre à un message après la migration.
· Le partage de l’espace d’adressage SMTP
Ivan Robain, lors d’une de ses récentes missions sur le sujet a su tirer une synthèse tout à fait intéressante sur ce premier point, en particulier à propos du « usual suspect » n°1 : le LegacyExchangeDN (aka LDN):
http://blogs.technet.com/frmcsuc/pages/migration-101-legacyexchangedn.aspx