PI Services

Le blog des collaborateurs de PI Services

Skype for Business – Accès à la messagerie vocale depuis un téléphone

Contexte

Lors de l’installation d’un téléphone Skype (type Polycom VVX400 ou AudioCodes 440HD) l’appel vers la messagerie vocale de l’utilisateur ne fonctionne pas.

En appelant la messagerie depuis le client Skype for Business l’appel fonctionne.

Solution

La connexion des téléphones au compte Skype de l’utilisateur se fait via les serveurs Skype for Business mais la messagerie vocale se trouve sur les serveurs Exchange (rôle UM) et non pas sur les serveurs Skype for Business.

Pour faire fonctionner les appels vers la messagerie vocale il faut donc ouvrir certains ports des téléphones vers les serveurs Exchange :

Source Destination Ports
VLAN VOIP IP Exchange Server (rôle UM) TCP : 5060, 5061, 5062, 5063, 5065, 5066, 5067, 5068
VLAN VOIP IP Exchange Server (rôle UM) UDP : 1024 à 65535

Exchange / Powershell : Influence du paramètre DomainController

Introduction

 

Exchange bénéficie d'un grand nombre de cmdlet Powershell très abouties et permettant de configurer et d'administrer l'intégralité d'une infrastructure de messagerie. Aussi, celles-ci sont très utiles dans le cas de scripts de provisionning. J'ai rencontré une erreur lorsque je cherchais à créer et à configurer un grand nombre de boites aux lettres de ressources.

 

Contexte

 

L'environnement dans lequel j'ai découvert ce problème est une forêt mono domaine Active Directory avec une infrastructure Exchange 2010 SP3 dans laquelle il y avait plusieurs contrôleurs de domaine dans le même site Active Directory que la totalité des serveurs de messagerie.

 

Plus globalement, cette erreur pourra être rencontrée dès qu'un serveur Exchange pourra être amené à interroger plus d'un contrôleur de domaine.

 

Erreur rencontrée

 

Dans un script de provisionning de boîtes aux lettres, on cherche à les créer mais aussi à les configurer. Si l'on souhaite configurer une boite aux lettres tout de suite après sa création alors on obtient une erreur similaire à celle ci-dessous (“ObjectNotFoundException”) :



Cela peut se retrouver en exécutant l'exemple suivant :



Une ou plusieurs opérations de modification (de type Set-…) vont échouer avec le message d'erreur cité précédemment.

 

Explication

 

Suite à cette erreur, il est logique de penser que cela est dû à l'interrogation de différents contrôleurs de domaine qui n'ont pas encore répliqué entre eux (Une réplication intra site peut prendre quelques secondes).

 

Aussi, on peut se dire qu'il suffit alors de spécifier le paramètre DomainController pour corriger le problème en l'indiquant sur toutes les commandes et en définissant un contrôleur de domaine unique qui traitera toutes les opérations.

 

Cependant, cela ne corrigera pas le problème. Microsoft en donne l'explication dans les fiches Technet des cmdlets :http://technet.microsoft.com/en-us/library/dd335046.aspx.

 

Le paramètre DomainController ne concerne que le contrôleur de domaine qui va écrire les modifications dans Active Directory. Cependant, un autre contrôleur de domaine  peut être utilisé pour lire l'objet avant d'écrire les changements sur celui spécifié en paramètre.

 

Aussi, pour une cmdlet de type Get-… (lecture), le paramètre DomainController sera bien le contrôleur de domaine sur lequel l'objet sera lu (cela sera utile pour mettre en place l'une des solutions proposées).

 

Solution

 

Pour résoudre ce problème,  il faut donc attendre que la réplication ait eu lieu sur la totalité des contrôleurs de domaine du site Active Directory de l'infrastructure Exchange. Pour cela, nous avons trois solutions.

 

Solution 1 :

 

Il est possible de séparer la création des boîtes aux lettres et leurs configurations. Cette solution oblige donc a réaliser le provisioning en plusieurs phases.

 

Solution 2 :

 

On peut définir un délai entre l'opération de la cmdlet de création et la cmdlet de configuration via un Start-Sleep par exemple. Cependant, cette solution ne garantit pas que les opérations vont toutes se dérouler correctement. Il faudra sans doute que le délai soit important pour que le provisioning ait un taux de réussite élevé et donc augmenter considérablement le temps d'exécution du script.

 

Solution 3 :

 

La dernière solution est une combinaison des deux précédentes puisqu'elle permet de n'avoir qu'une seule phase de provisioning tout en ayant un temps d'exécution relativement rapide.

 

Cette solution consiste à implémenter une boucle de test de l'opération à réaliser sur le même contrôleur de domaine via la cmdlet de lecture (Get-…).

 

Exemple :



Il est possible d'ajouter une courte pause entre chaque test afin de ne pas surcharger le processus sans pour autant trop pénaliser le temps d'exécution du script. Le paramètre ErrorAction permet d'alléger l'affichage car on connait déjà l'erreur que l'on va rencontrer.

Il ne vous reste plus qu'à choisir la solution que vous préférez.

Retour d'expérience : Migration de tenant Office 365 Partie 2

Introduction

Cet article divisé en deux parties est un retour d'expérience sur une migration entre tenant Office 365. Il ne traitera pas de tous les services disponibles sur Office 365 mais seulement de ceux rencontrés lors de la migration (voir Contexte). La première partie traitait de la migration des licences, du SSO (ADFS) et de Dirsync (http://blog.piservices.fr/post/Retour-dexperience-Migration-de28099un-tenant-Office-365-Partie-1.aspx). Cette seconde partie sera consacré aux autres services d'Office 365 (Yammer, Exchange Online, Sharepoint Online).

Contexte

Pour rappel, la société possédait deux tenant et souhaitait migrer les services de l'un des deux (nommé ici myenterprise1) vers le second (nommé ici myenterprise2). Pour chaque service, un listing des étapes à réaliser sera détaillé.

Exchange Online

Il n'existe pas de réel procédure pour la migration de boîtes aux lettres entre tenant. Le processus ci-dessous est manuel. Globalement, il consiste à exporter les boîtes aux lettres au format PST, à migrer le domaine SMTP puis à recréer les boîtes aux lettres sur le nouveau tenant. Cette procédure est entièrement manuelle. Voici un listing chronologique des étapes à appliquer :

  • Configuration du domaine SMTP sur le nouveau tenant (myenterprise2). Il ne faut bien évidemment pas faire la vérification mais simplement créé les enregistrements et valider qu'ils sont bien visibles avant de passer à l'étape suivante. Cela permet de réduire la coupure de service à quelques minutes. Si les enregistrements DNS ne sont pas créés en amont, le service peut être coupé le temps de la création de ceux-ci et de la propagation dans les DNS (cela peut durer 24H).
  • Création des utilisateurs sur le nouveau tenant (positionnement d'un suffixe UPN en *.onmicrosoft.com). Cela permet de gagner encore un peu de temps sur la coupure de service.
  • Sauvegarde des boîtes aux lettres sur l'ancien tenant (myenterprise1) au format PST (via Outlook par exemple).
  • Changement de domaine des utilisateurs sur l'ancien tenant (myenterprise1). Il suffit de définir leurs suffixes UPN sur le domaine *.onmicrosoft.com afin qu'il n'interfère pas avec la migration du domaine SMTP.
  • Suppression du domaine SMTP de l'ancien tenant (myenterprise1) Office 365.
  • Vérification du domaine sur le nouveau tenant et attribution de l'intention de domaine de type Exchange Online.
  • Changement du domaine d'appartenance des utilisateurs sur le nouveau tenant (mise en place du nouveau domaine SMTP).
  • Activation des boîtes aux lettres pour les utilisateurs sur le nouveau tenant (myenterprise2).
  • Import du PST d'export réalisé précédemment pour chaque boîte aux lettres sur le nouveau tenant (myenterprise2).
  • Reconfigurer les clients Outlook. Il est nécessaire de supprimer le profil et de le recréer pour que la boîtes aux lettres soit accessible.

Toutes les étapes de changements d'UPN sont automatisables via Powershell avec la commande Set-MsolUserPrincipalName (voir script de la section Modification des utilisateurs de la partie 1).

Cette procédure est donc valable pour un faible nombre de boîtes aux lettres. Si le volume de boîte aux lettres est trop important, il reste deux solutions possibles mais plus lourdes et/ou plus onéreuses :

  • Migrer vers une infrastructure On Premise Exchange (scénario prévu par Microsoft) puis rebasculer sur le nouveau tenant Exchange Online.
  • Utiliser des outils de migrations payants.

Sharepoint Online

Comme pour d’autres services Office 365, la migration d’un site Sharepoint Online est manuelle. La migration se déroule en cinq étapes :

  1. Récupération du contenu
  2. Génération d’un modèle
  3. Import du modèle
  4. Intégration du contenu
  5. Paramétrage du nouveau site : il s’agit de reconfigurer les paramètres comme les autorisations utilisateurs.

Nous allons nous intéresser à la migration du contenu, à la génération du modèle de site et à l’import de ce dernier.

Migration du contenu

Afin de migrer le contenu d’un site Sharepoint Online, il faut utiliser OneDrive. Il est nécessaire de se connecter au site web à migrer est de copier tout le contenu du site. Néanmoins si votre site possède moins de 50Mo de contenu, il suffira de l’inclure dans le modèle. En effet, ce dernier peut inclure du contenu si celui-ci ne dépasse pas cette limite de taille.

NB : Il existe aussi des outils de migrations payant.

Génération du modèle de site

La génération du modèle de site se fait via la console d’administration du site (Paramètre du site).

image Dans la section Action du site, il faut choisir “Enregistrer le site en tant que modèle”.

image

Un assistant vous proposera ensuite de donner un nom au modèle et éventuellement d’inclure le contenu du site (cette opération n’est fonctionnelle que si votre contenu pèse moins de 50Mo).

image

Vous pourrez ensuite accéder à la galerie des solutions et télécharger le modèle au format .wsp.

NB : L’option “Enregistrer le site en tant que modèle” n’est parfois pas disponible. Pour l’activer, il faut utiliser Sharepoint Designer 2013. Il est nécessaire d’ouvrir le site depuis ce logiciel en spécifiant son url et de choisir “Options de site” dans le ruban.

image

Enfin, il faut changer la valeur du paramètre “SaveSiteAsTemplateEnabled” à “True” et appliquer le changement. Ainsi, l’option d’enregistrement du site en tant que modèle sera disponible dans les paramètres du site Sharepoint.

image 

Import du modèle de site

Pour importer un modèle de site, il suffit de créer un nouveau site en spécifiant un modèle personnalisé (le modèle devra être fourni ultérieurement).

image

Enfin, il faut ouvrir le nouveau site web et choisir “Galerie Solution” dans lors du choix du modèle. Ce lien vous mènera à une fenêtre permettant de charger le fichier .wsp précédemment créé via le bouton “Télécharger la solution”.

image 

Yammer

Yammer étant un service encore peut intégré avec Office 365, il est plus facile à migrer entre deux tenants. Tout d'abord, il est nécessaire de supprimer le domaine qui correspond au nom du réseau Yammer sur l'ancien tenant(myenterprise1). Il s'agit ensuite de l'ajouter sur le nouveau tenant (myenterprise2).

Si le domaine n'est pas fédéré, il faut que ce dernier soit défini comme domaine par défaut de Yammer. Dans le cas contraire, une erreur est remontée au moment de l'activation du service Yammer. Pour réaliser cette opération, il suffit de se rendre dans le listing des domaines, de sélectionner le bon domaine est de cliquer sur l'option “Définir par défaut”.

Yammer Domain

Nous pouvons ensuite activer Yammer sur le nouveau tenant (myenterprise2). Dans le panneau d'administration d'Office 365, il faut cliquer sur “Tableau de bord” puis choisir “Service Inclus”. Un nouveau panel apparaît sur la droite permettant d'activer Yammer.

Yammer

On peut ensuite confirmer l'activation du service.

Yammer Enable Yammer Enable 2

Le réseau Yammer est rattaché au nouveau tenant dès que le service est activé. Il existe deux types d'administrateurs sur Yammer :

  • des administrateurs déclarés directement dans Yammer
  • des administrateurs héritant de ces droits car ils possèdent le rôle administrateur général du tenant

Les premiers ne subissent aucune perte de droits pendant la migration. Cependant pour la seconde catégorie, il est nécessaire que les utilisateurs aient un compte avec le rôle administrateur général sur le nouveau tenant sinon ils perdront les droits d'administration de Yammer en plus des droits d'administration du tenant (on peut aussi les déclarés directement dans Yammer si on ne souhaitent plus qu'ils soient administrateurs du tenant).

Concernant Yammer Dirsync, comme ce dernier n'interagit pas avec Office 365 (il s'agit d'un second produit de synchronisation différent d'Office 365 Dirsync), il n'y a aucune manipulation à réaliser. Il en est de même pour la configuration du SSO via ADFS.

OneDrive

Concernant OneDrive, il faut, pour chaque utilisateur :

  • Arrêter la synchronisation du dossier
  • Désactiver l'utilisateur sur l'ancien tenant (myenterprise1)
  • Créer son compte sur le nouveau tenant (provisionning manuel ou via Dirsync)
  • Synchroniser le nouveau dossier personnel dans lequel on copiera le contenu qui aura été conservé en local sur la machine.
    OneDrive

Il existe des outils payant si vous souhaitez automatiser le transfert des données entre les deux tenants. Néanmoins, il restera à reconfigurer le client OneDrive.

Conclusion

Contrairement à la migration du SSO et de la synchronisation Dirsync qui est plus structurée (bien qu'il n'existe pas non plus de procédure officielle), la migration de services Office 365 entre tenant est actuellement totalement manuelle et relève plus d'astuces que de réels procédures.

DirSync – Changement de l’adresse e-mail recevant les alertes

Contexte

Lors de la mise en place de DirSync dans une architecture, ce dernier envoie automatiquement des mails lors des problèmes de synchronisation.

Problème

L’adresse e-mail utilisée par DirSync n’est plus consultée et nous ne recevons plus d’alertes.

Solution

DirSync utilise l’adresse e-mail principale du tenant Office 365 (l’adresse enregistrée à la création du tenant). Il faut donc modifier cette adresse pour recevoir les alertes DirSync.

Une fois connecté au portail d’administration d’Office 365, il faut cliquer sur le nom de la société en haut à droite de la page. Puis il est possible de modifier les informations du compte principal, notamment l’adresse e-mail.

image

image

Exchange 2013 CU6 – Problèmes lors de la coexistence avec Exchange 2007

Contexte

Lors d’une migration d’Exchange 2007 vers Exchange 2013 CU6 (dernière version en date) certains problèmes sont rencontrés lors de la coexistence entre les deux systèmes.

Problématique

Les problèmes rencontrés sont les suivants :

  • Problèmes de cohabitation sur le protocole ActiveSync
  • Bascule des bases de données Exchange de façon aléatoire

Ces deux problèmes sont résolus par deux hotfix que Microsoft délivre seulement sur demande au support :

Cependant le passage de ces correctifs peut engendrer deux nouveaux problèmes :

  • Impossibilité d’accéder à l’OWA
  • Impossibilité d’écrire un mail dans OWA

Solution

Pour résoudre ces problèmes il faut se connecter sur le serveur Exchange puis identifiez les deux dossiers suivants :

  • Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.0.995.31
  • Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.0.995.29
    exchange

Le contenu des dossiers doit être identique. Sauvegardez le contenu du dossier 15.0.995.31 puis copiez les éléments du dossier 15.0.995.29 vers le dossier 15.0.995.31.

N.B : Le CU7 d’Exchange 2013, disponible très prochainement, devrait intégrer les deux correctifs (KB2997847 et KB2997203).

Exchange : Découverte de l'agent de scripting

Introduction

Depuis Exchange 2010, il existe les agents d'extension des Cmdlets. C'est une fonctionalité méconnue (car peu documentée) et pourtant très utile dans beaucoup d'entreprise.

Ces agents permettent d'étendre les fonctionnalités de base d'Exchange. Par exemple lors de la création d'une boîte aux lettres, si une base de données n'est pas renseignée alors un agent se charge d'en choisir une automatiquement. Quelque soit le mode d'administration (Powershell ou via la console graphique EMC), l'agent se lancera. Cela vient entre autre du fait que la console Exchange ne fait qu'exécuter du Powershell en tâche de fond. Il est possible d'obtenir la liste de ces agents en exécutant la Cmdlet suivante dans une session Powershell Exchange :

Voici le résultat obtenu sur une infrastructure sans paramétrage particulier de ces agents :

Exchange Extension Agent Listing

Il existe de nombreux agents ; notamment pour la gestion de l'OAB ou des boîtes aux lettres. Dans le résultat obtenu, 2 attributs vont nous intéresser : l'activation et la priorité. Le premier permet simplement de savoir si l'agent est actuellement utilisé ou non. Le second concerne l'ordre d'application. En effet, plusieurs agents peuvent agir sur la même chose (par exemple : le choix de la base de données pour une boîte aux lettres). La priorité permet de définir l'agent qui sera utilisé (celui qui a la priorité la plus basse, les autres ne seront pas utilisés). Pour changer la priorité d'un agent, il suffit d'utiliser la commande suivante :

L'agent qui nous intéresse dans cet article est le "Scripting Agent". Nous allons voir comment l'utiliser ainsi que quels exemples d'utilisation.

L'agent de script

A contrario des autres agents, l'agent de scripting est entièrement customisable par les administrateurs Exchange. Typiquement, il va nous permettre par exemple, de réaliser certaines actions au moment de la création d'une boîte aux lettres et donc de l'exécution de la commande New-Mailbox ou Enable-Mailbox (activer/désactiver POP3/Single item recovery etc, création d'une boîte d'archive, envoi d'un mail automatique à l'utilisateur). On peux aussi imaginer un export automatique de la boîte aux lettres au format PST lorsque la commande remove-mailbox sera lancée. D'autres types d'actions sont réalisables. Elles seront détaillées plus loin dans cet article. Tout type de script Powershell peux être intégré.

Par défaut l'agent de scripting n'est pas activé. C'est pourquoi, on utilise la commande :

Cette commande active l'agent de scripting sur tous les serveurs Exchange de l'organisation.

Attention : Le fichier de configuration doit être présent sur tous vos serveurs Exchange. En effet, si l'agent de scripting est activé et que l'un des serveurs ne possède pas le fichier alors des erreurs peuvent survenir lorsque l'on appelle une commande Powershell ou lorsqu’on lance la console Exchange (impossibilité de se connecter au serveur ne possédant pas le fichier de configuration).

L'agent de scripting ne possède aucune configuration par défaut. Il convient aux administrateurs Exchange de la créer. Celle-ci se fait au travers du fichier ScriptingAgentConfig.xml qui doit être positionné dans le dossier C:\Program Files\Microsoft\Exchange Server\V14\Bin\CmdletExtensionAgents (à moduler suivant le répertoire d'installation d'Exchange). Un exemple existe dans ce même répertoire nommé ScriptingAgentConfig.xml.sample).

Ce fichier contiendra tous nos scripts d'automatisation. Regardons maintenant la hiérarchie de ce fichier XML :

La balise Configuration contient l'ensemble des scripts qui seront utilisés par l'agent de scripting. C'est la balise racine.

Les balises Feature contiennent chaque fonctionnalité que l'on souhaite ajouter. Il peut y en envoir plusieurs au sein d'une balise Configuration. Elle possède chacune 2 attributs :

  • Name : pour le nom que l'on souhaite donner à notre fonctionnalité)
  • Cmdlets : permet de spécifier les Cmdlets Powershell Exchange qui vont déclencher la fonctionnalité. S'il y en a plusieurs, elles doivent être séparées par des virgules (Exemple : "New-Mailbox,Enable-Mailbox").

La balise API Call précice à quel moment la fonctionnalité se déclenche. Elle contient aussi le script qui sera lancé au déclenchement. Il peux y en envoir plusieurs au sein d'une balise Feature. Elle possède un attribut Name qui peut avoir 4 valeurs possibles :

  • OnComplete : Le script fourni sera exécuté lorsque la commande appelé aura déjà été exécuté. Exemple : Après la création d'une boîte aux lettres, on souhaite envoyer un mail de bienvenu à l'utilisateur et activer le Single Item Recovery.
  • Validate : Utile lorsque l'on souhaite valider des attributs. Le script se déclenchera avant l'exécution de la commande. Exemple : On souhaite être sur que les attributs Location et Phone ont été renseignés ou qu'ils respectent une certaine nomenclature pendant la création d'une boîte aux lettres. Ainsi l'administrateur recevra une erreur lors de l'exécution de la commande comme si ces attributs étaient obligatoire. Lorsque le retour est $null alors l'étape de validation est un succès.
  • ProvisionDefaultProperties : Cela permet de définir des valeurs par défaut pour les propriétés d'un objet. Exemple : Lorsque l'on crée une boîte aux lettres Exchange, on peux imaginer une règle qui choisit automatiquement la base de données en fonction de la première lettre du nom de la personne. Attention, dans cet exemple, il est nécessaire de désactiver l'agent Mailbox Resources Management ou de baisser sa priorité en dessous de celle de l'agent de scripting. En effet, l'agent Mailbox Resources Management est en charge de l'attribution automatique d'une base de données si aucune n'est renseignée.
  • UpdateAffectedIConfigurable : Cette API offre la possibilité de définir des propriétés juste avant l'opération de validation.

L'ordre d'exécution des différentes API lorsque l'on exécute une commande Exchange est le suivant  :

ProvisionDefaultProperties - UpdateAffectedIConfigurable - Validate – OnComplete

L'exécution de la commande Powershell Exchange a lieu entre les étapes Validate et OnComplete.

Enfin la balise Common permet de définir des fonctions Powershell pouvant être utilisées dans les scripts des balises ApiCall (A utiliser comme une librairie). On peut aussi charger ses propres scripts Powershell.

La mise en forme du fichier ScriptingAgentConfig.xml est importante. En effet, il apparait que lorsque des espaces inutiles sont présents, Exchange génère une erreur similaire à celle ci-dessous :

ScriptingAgent Error

De plus, un événement est généré :

ScriptingAgent Error Event 

Pour ma part, afin d'éviter tout problème, je me suis rendu compte qu’il ne fallait mieux pas commenter les scripts présents dans le fichier xml.

NB : Une fois l'agent de scripting activé, les modifications du fichier ScriptingAgentConfig.xml sont prises en compte automatiquement.

Exemple d'utilisation avec l'événement OnComplete :

Lorsqu'on utilise l'API OnComplete, la variable $succeeded existe si la commande a réussi. Cela permet de gérer les cas d'échecs (il serait impossible d'effectuer un traitement sur une boîte aux lettres qui n'existerait pas).

L’exemple ci-dessous est un fichier ScriptingAgentConfig.xml permettant d’activer la boîte d’archive et le single item recovery lorsqu’une nouvelle boîte aux lettres Exchange est créée (Commande New-Mailbox et Enable-Mailbox). On remarque que l’on accède aux paramètres définis par l’utilisateur via la variable $provisioningHandler qui contient un hastable nommé UserSpecifiedParameters.

Exemple d'utilisation avec l'événement Validate : 

Ce nouvel exemple montre cette fois-ci l'usage de l'API Validate. Ici, lorsqu'une boîte aux lettres de salle est créée, on vérifie que son nom est bien du type : Salle, XX où XX est un nombre. Si le test échoue alors une erreur est retourné avec un message qui sera affiché pour l’administrateur (que l’action soit réalisée via EMS ou l’EMC).

Powershell : Connexion à Exchange Online

Introduction

Powershell est intégré dans tous les nouveaux produits et services de Microsoft. Grâce à ce langage de scripting il est tout naturellement possible d'administrer Exchange Online via le Remote Powershell. Au delà d'offrir des possibilités d'automatisation, certaines opérations ne sont réalisables que par ce biais.

La gestion d'Exchange Online se décompose en 2 parties :
L'installation d'un module Powershell pour la gestion des utilisateurs dans l'Active Directory Azure
La connexion à Exchange Online pour l'administration des paramètres de la messagerie et des boîtes aux lettres.

Cet article s'adresse donc aux personnes souhaitant administrer Exchange Online mais aussi à ceux qui utilisent Active Directory dans le cloud Azure.

Nous allons voir comment accéder à la gestion des utilisateurs sur Office 365, à leurs boîte email Exchange Online. Je montrerai aussi quelques erreurs courantes (problème d'installation et connexion derrière un proxy) que l'on peut rencontrer lors d'une interaction avec Office 365 ainsi que leurs résolutions.

A noter que, comme les sessions distantes Powershell sont apparues avec la version 2, il est nécessaire de posséder à minima cette version pour exécuter les opérations que nous allons voir.

Gestion des utilisateurs Microsoft Online (Azure Active Directory)

Installation :

L'administration des utilisateurs ne peut se faire que via l'installation d'un module Powershell. Ce dernier nécessite un prérequis : Microsoft Online Services Sign-In Assistant. Ci dessous, vous trouverez les liens de téléchargement de ce dernier :

Microsoft Online Services Sign-In Assistant– 32 bit version
http://go.microsoft.com/fwlink/?linkid=236299
Microsoft Online Services Sign-In Assistant – 64 bit version
http://go.microsoft.com/fwlink/?linkid=236300

Voici maintenant les liens pour récupérer le module Powershell :

Microsoft Online Services Module for Windows PowerShell (32-bit version)
http://go.microsoft.com/fwlink/?linkid=236298
Microsoft Online Services Module for Windows PowerShell (64-bit version)
http://go.microsoft.com/fwlink/?linkid=236297

Vérification de l'installation :

Pour vérifier que le module est opérationnel, il suffit de l'importer et de se connecter aux services MSOnline (en s'authentifiant lorsque c'est demandé) :
On peut ensuite utiliser les commandes comme :

Erreurs rencontrées :

1/ Lors de l'installation de Microsoft Online Services Sign-In Assistant, j'ai rencontré l'erreur suivante :

In order to install Windows Azure Active Directory Module for Windows PowerShell, you must have Microsoft Online Services Sign-In Assistant version 7.0 or greater installed on this computer.

Pour résoudre ce problème, il m'a fallu installer la beta de ce prérequis disponible dans le lien ci-dessous :
http://www.microsoft.com/en-us/download/details.aspx?id=39267

2/ Si un proxy est utilisé lors de la connexion au cloud de Microsoft, alors on obtient l'erreur suivante :

Erreur Proxy

Pour résoudre ce problème, il faut configurer le proxy ainsi que les paramètres d'authentification à utiliser :

Par défaut Powershell utilise le proxy d'Internet Explorer ; on peut reconfigurer le paramétrage du proxy avec la commande « netsh ».

On spécifie une URL de proxy (première ligne) ou on indique que l'on souhaite utiliser les paramètres présents dans Internet Explorer (seconde ligne) :
Aussi, on peut aussi supprimer toute configuration du proxy via la commande suivante :
Pour que Powershell puisse s'authentifier, il faut indiquer un couple login / mot de passe. En général, on utilisera ceux de la session actuellement ouverte. Pour effectuer cette opération, il suffit d'exécuter la commande suivante :

Connexion à Exchange Online

Implémentation :

Le but de l'opération est d’importer toutes les commandes que l’on connait sous Exchange comme « Get-Mailbox » qui existent aussi sous Exchange Online.
Voici les quelques lignes Powershell permettant d'ouvrir une PSSession vers Exchange Online en spécifiant un compte utilisateur pour s'authentifier puis d'importer les cmdlets Exchange. A noter que la liste des commandes disponibles variera en fonction des droits du compte utilisé (grâce à RBAC).

Erreur rencontrée :

Comme pour la gestion des utilisateurs Active Directory dans le cloud, une configuration particulière est attendue lorsque l'on essaie de se connecter en passant par un proxy. L'erreur générique suivante apparaît :

Erreur Proxy Exchange

Pour résoudre ce problème, il est possible d'utiliser la même méthode que précédemment. Cependant, on peut aussi définir les paramètres des sessions Powershell distantes et ainsi configurer un proxy. Dans l'exemple ci-dessous nous utiliserons le proxy défini dans Internet Explorer :

La variable $Credential contient les paramètres d’authentification.

Exchange 2013 - Erreur 5203 (source WAS) sur un serveur multi-rôles Exchange 2013 CU2

Symptômes

Ce type d’erreur peut se rencontrer sur un serveur multi-rôles (Client Access et Mailbox) en version Exchange Server 2013 CU1 ou Exchange Server 2013 CU2.

Les symptômes sont les suivants :

  • Les services Web Exchange (OWA, Outlook Anywhere…) dysfonctionnent
  • L’erreur 503 (source WAS) est présente en boucle dans le journal d’évènement Système

    Voici le détail de l’erreur concernée :

    Journal : System
    Source: Microsoft-Windows-WAS
    Event ID : 5203
    Level : Error
    Description: A process serving application pool 'MSExchangeRpcProxyAppPool' reported a failure trying to read configuration during startup. The process id was '27620'.  Please check the Application Event Log for further event messages logged by the worker process on the specific error.  The data field contains the error number.

Explication

Cette erreur est généralement due à la présence d’un fichier de configuration IIS corrompu.

Cela peut être mis en évidence en lançant la console d’administration IIS Manager.

image

Dans notre exemple, la console fait très clairement référence à un fichier de configuration nommé applicationHost.config et stocké dans le répertoire C:\Windows\System32\Inetsrv\Config.

Lorsque l’on tente d’éditer le fichier, ce dernier peut apparaitre remplis d’espace blancs ou bien ma formaté (selon les cas de figure).

image

Résolution

Pour résoudre ce problème il suffit de recopier le fichier sur le serveur applicationHost.config à partir d’un autre serveur Exchange en même version ou bien à partir d’une sauvegarde.

Dès le fichier copié, il devient  possible de démarrer les services IIS et les services Web sont de nouveau opérationnels.

Exchange 2010 SP2 – Erreur MapiExceptionNetworkError lors du déplacement des boîtes aux lettres

Symptôme

Dans le cadre d’une migration depuis une plateforme Exchange Server 2007 SP3 vers une plateforme Exchange 2010 SP2 RU5v2, l’erreur MapiExceptionNetworkError apparaît de manière régulière dans les logs des requêtes de déplacement de boîtes aux lettres (MoveRequests).

Voici un exemple :

18/01/2013 19:03:15 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:13:54 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:19:31 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:25:48 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:36:51 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:42:58 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 19:53:52 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:00:00 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:11:11 [SRV] Transient error MapiExceptionNetworkError has occurred.
18/01/2013 20:17:22 [SRV] Transient error MapiExceptionNetworkError has occurred

Le code d’erreur détaillé est le suivant :

Error details: MapiExceptionNetworkError: Unable to open entry ID. (hr=0x80040115, ec=0)

Les déplacements de boîtes aux lettres ne se terminent jamais car à chaque occurrence de l’erreur réseau, le transfert des données depuis les serveurs Exchange 2007 vers les serveurs Exchange 2010 repart à zéro.

18/01/2013 20:17:53 [SRV] Restarting the move because checkpoint data doesn't exist or isn't valid in 'Primary (f3e507d4-a687-416b-a615-23d2b9173011)'.
18/01/2013 20:17:53 [SRV] Connected to source mailbox 'Primary (f3e507d4-a687-416b-a615-23d2b9173011)', database 'CLUST01\StorageGroup\DB001', Mailbox server 'CLUST01.domain.local' Version 8.3 (Build 213.0).
18/01/2013 20:17:54 [SRV] Request processing started.
18/01/2013 20:17:54 [SRV] An old copy of the mailbox was removed from the destination database. The operation will try again in 30 seconds.

 

En parallèle, on remarque sur les boîtes aux lettres migrées vers Exchange 2010, l’apparition de nombreux évènements ayant pour source Outlook et pour ID 26 sur les postes clients (équipés d’Outlook 2010).

image

L’évènement émis par Outlook avec ID 26 a pour description “La connexion MAPI a été rétablie”.

Explication

Par défaut les sessions MAPI initiées par les serveurs Exchange 2010 ont une durée de vie de deux heures (7200 secondes).

Il peut arriver qu’un équipement réseau (routeur, pare-feu, HLB…) détecté une connexion MAPI comme étant inactive (idle) et coupe la session. En cas de coupure de session les clients MAPI tentent généralement de se reconnecter.

Dans notre cas c’est ce qui se produisait d’une part avec les clients Outlook (d’où les nombreux évènements au sujet d’une connexion MAPI “rétablie”) et d’autre part lorsque les serveurs CAS déplaçaient des boîtes aux lettres (d’où les erreurs “réseau”, suivies d’une reprise de la copie à son état de départ).

Remarque : Cette problématique de timeout est documentée dans la fiche support KB 2535656 (http://support.microsoft.com/kb/2535656/en-us) mais l’impact possible sur les déplacement de boîtes aux lettres (erreur “MapiExceptionNetworkError: Unable to open entry ID) n’y est pas référencé.

Résolution

Pour résoudre ce problème, deux approches sont possibles :

A) Identifier l’équipement réseau possédant un timeout trop court et reconfigurer ce timeout sur une valeur cohérente avec celle d’Exchange 2010 (2 heures)

B) Identifier la durée du timeout (dans notre cas 300s) et ajouter la clé de registre KeepAliveTime sur l’ensemble des serveurs Exchange 2010 et 2007 pour que le timeout Exchange soit inférieur au timeout de l’équipement (par exemple positionner la valeur KeepAlive sur 180 secondes)

Dans notre cas de figure l’option la plus simple et la plus pertinente a consisté à augmenter le timeout du “protocol profil” FastL4 sur les boitiers F5 (par défaut le timeout sur ce profil était configuré à 300 secondes et il a été relevé à 7200 secondes).

clip_image001[4]

Cette opération a résolu l’ensemble des problèmes rencontrés sur la plateforme (plus d’erreurs 26 sur les clients ni d’erreur MapiNetworkException lors des transferts de boîtes aux lettres).

A titre informatif, voici un exemple de configuration de la clé KeepAliveTime (attention la valeur à entrer est en millisecondes).

image

Exchange 2010 SP2 – Message d’erreur “invalid canary” sur les serveurs CAS

Symptôme

Suite à la mise en place de la supervision SCOM sur une plateforme Exchange 2010 SP2 RU5v2, des erreurs se produisent toutes les 5 minutes sur les serveurs jouant le rôle CAS.

image

Ces erreurs ont pour source MSExchange Control Panel et correspondent aux ID 4 et 38. Voici le détail de l’erreur 38 (avec en rouge les éléments intéressants) :

Log Name: Application
Source: MSExchange Control Panel
Date: 15/01/2013 14:40:05
Event ID: 38
Task Category: General
Level: Error
Keywords: Classic
User: N/A
Computer: CAS003.domain.local
Description:
Current User: 'domain.local/IT/Applications/Exchange/Sepcial Accounts/extest_123sd45c00812'

Exchange Control Panel detected an invalid canary from request for URL 'https://mail.domain.local/ECP/RulesEditor/InboxRules.svc/GetList'.

Canary in cookie: 'eLKJ8_Sgdekahjnd4825nduehfrkqzeuYDF_ujrDBHjfznakDF46fhbzp' mismatch with canary in header/form: ', in URL '.


Du côté de IIS, une erreur 500 est déclenchée et visible dans les logs W3C.

Explication

Ces erreurs se produisent à intervalles réguliers (toutes les 5 minutes) lorsque le compte de service utilisé par SCOM (extest_<id>) tente d’exécuter la commande PowerShell Test-EcpConnectivity.

Lorsque l’on effectue des recherches sur ces erreurs ont tombe très rapidement sur une fiche support indiquant qu’il s’agit d’un bug Exchange 2010 résolu dans la mise à jour RU3v3 du SP1 d’Exchange 2010.

Unnecessary events are logged in the Application log when you run the "Test-EcpConnectivity" cmdlet in an Exchange Server 2010 environment
http://support.microsoft.com/kb/2494389/en-us

Néanmoins dans notre cas, l’environnement est déjà mis à jour en version SP2 RU5v2 ce qui rend cette solution caduque.

Après investigation il s’avère que la commande Test-EcpConnectivity ne supporte pas les URL possédant des majuscules.

La solution au problème consiste à modifier les URL internes et externes du service Web ECP (Exchange Control Panel) de manière à remplacer le /ECP par un /ecp.

Ce problème est donc totalement indépendant de la supervision SCOM qui est dans ce cas un simple révélateur du problème (car SCOM exécute régulièrement la cmdlet Test-EcpConnectivity).

Résolution

Dès la correction des URL (via la cmdlet Set-EcpVirtualDirectory), les erreurs ne se produisent plus et il est possible d’exécuter sans erreur la commande Test-EcpConnectivity.

Remarque : La correction prend effet immédiatement. Un petit délai peut être nécessaire dans certains environnements, le temps que la réplication Active Directory ait lieu. Il n’est pas nécessaire de redémarrer IIS.

Cette solution a déjà été testée avec succès sur plusieurs environnement Exchange 2010 SP2.