PI Services

Le blog des collaborateurs de PI Services

Exchange 2010 - Erreur de synchronisation des bases après la migration d'un serveur Mailbox virtualisé

Contexte

Après la migration d'un serveur Mailbox virtualisé vers un nouvel hoster, la réplication des bases Exchange ne fonctionne plus et le message d'erreur suivant est présent lorsque la commande Test-ReplicationHealth est utilisée :

The log copier was unable to continue processing for database DAG\MBX because an error occured on the target server: Continuous replication - block mode has been terminated. Error : the log file sector size does not match the current volume's sector size (-546)

Problèmatique

Ce problème est causé par un changement de la taille de secteur physique des disques sur lesquels les bases sont. Le problème intervient lorsque le nouvel hoster est plus récent que l'ancien et qu'il ne possède pas le même firmware pour le stockage. Exchange n'est pas en capacité de supporter automatiquement le changement d'un disque avec des secteurs de 512 bytes vers un disque avec des secteurs de 4096 bytes.

Pour vérifier cela, lancer la commande suivante : fsutil fsinfo ntfsinfo <Disk>

On remarque que le paramètre Bytes Per Physical Sector n'est pas supporté.

Solution

La solution pour reprendre la synchronisation des bases est de désactiver la réplication granulaire dans un premier temps. Pour cela, créer la clé de registre DWORD suivante avec la valeur 1 :

HKLM\Software\Microsoft\ExchangeServer\v14\Replay\Parameters\DisableGranularReplication

Après avoir redémarré le serveur, si on relance la commande fsutil fsinfo ntfsinfo <Disk> le paramètre Bytes Per Physical Sector accepte désormais les secteurs en 4096 bytes.

A la suite de ce changement, la réplication fonctionne de nouveau correctement.

Remarque : Attention, Microsoft ne supporte pas que la méthode de réplication ne soit pas la même sur l'ensemble des noeuds d'un DAG. Il est donc nécessaire de revenir en arrière une fois le changement effectué ou de désactiver la réplication granulaire sur l'ensemble des noeuds.

L'ensemble de ce problème est expliqué plus en détails sur le lien TechNet : https://blogs.technet.microsoft.com/exchange/2013/04/24/exchange-2010-database-availability-groups-and-disk-sector-sizes/

Exchange 2010 – Page OWA vide après le passage d’un RU

Contexte

Après le passage d’un Rollup Update, lorsque vous vous connectez à l’OWA la page ne se charge pas et reste vide.

Dans le journal d’évènement l’erreur suivante est présente :

Outlook Web App couldn’t initialize.
A base theme couldn’t be found. The base theme must be in a folder with name = “base”

AA1

Solution

Pour résoudre cette erreur, il faut lancer le script UpdateCas.ps1 qui se trouve dans le dossier Scripts présent dans le répertoire d’Exchange Server.

A1

Exchange 2010 – Erreur “Flow of control cannot leave a Finally block”

Contexte

Lors d’un passage d’un Rollup Update ou d’un Service Pack (voir lors de l’utilisation d’un script PowerShell fourni par Microsoft), l’assistant d’installation d’Exchange 2010 échoue et l’erreur suivante est présente dans les logs :

Flow of control cannot leave a Finally block.

1

Solution

L’erreur provient d’une incompatibilité entre votre version de PowerShell et le script.

Pour résoudre l’erreur il faut regarder dans le fichier de log quel script et quelle ligne pose problème.

Ici c’est le script ManageScheduledTask.ps1 ligne 462 qui contient la commande return $success qui est en erreur.

2

Pour la résoudre il faut remplacer le return $success par Write-Output $success.

3

Une fois le script modifié, relancer l’assistant d’installation.

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.

Exchange 2010 / SCOM : Erreur après la désactivation de l’agent de scripting

Introduction

Dans un précédent article, nous avons découvert l'agent de scripting dans Exchange (http://blog.piservices.fr/post/Exchange-Decouverte-de-lagent-de-scripting.aspx). Pour rappel, cela permet  les fonctionnalités de base des cmdlets Exchange. Ainsi, on peut par exemple ajouter automatiquement une boîte d'archive au moment de la création de sa boîte aux lettres. Pour que cette opération fonctionne, il faut activer l'agent de scripting via la cmdlet “Enable-CmdletExtensionAgent”.

Cependant, si vous êtes amenés à désactiver cet agent ultérieurement, vous pouvez rencontrer de nombreuses erreurs avec l'event ID “6” dans le journal “MSExchange Management”.

Event

Ces erreurs peuvent être normales, lorsqu’un administrateur Exchange s'est trompé dans la syntaxe d'une cmdlet Powershell.

Contexte

Dans certaines situations ces erreurs sont à l’origine du mauvais  fonctionnement d'un composant tiers. En l'occurrence, comme nous allons le voir ici, il s'agit de System Center Operations Manager (SCOM). En effet, le Management Pack SCOM d'Exchange lance de nombreuses cmdlets afin d'effectuer des tests de vérification d'intégrité de l'infrastructure Exchange. A cause, de cette erreur, la supervision de l'infrastructure Exchange peut ne plus être opérationnelle.

Explication

Si on affiche l'erreur au format XML dans l’observateur d’événements, on obtient plus de détails :

 

Il est indiqué qu'Exchange ne trouve pas le fichier de configuration de l'agent de scripting : “File is not found: 'D:\Program Files\Microsoft\Exchange Server\V14\Bin\CmdletExtensionAgents\ScriptingAgentConfig.xml'”.

Cependant, si l'agent de scripting a été désactivé, il n'y a aucune raison qu'il soit utilisé. Pour rappel, le fichier de configuration ne doit être présent que si l'agent de scripting est démarré. Il est à noter que même si ce fichier est présent, l'erreur continue d'apparaître. Le message indiqué dans l'erreur n'est donc pas pertinent. En réalité, il s'avère que le service “Exchange Monitoring” ne prend pas en compte le changement de configuration. Il est utilisé par le management pack SCOM et permet d'executer toutes les cmdlets de diagnostics comme “Test-PopConnectivity”, “Test-MRSHealth”, “Test-ReplicationHealth”, ...

Résolution

Pour résoudre cette erreur, il suffit de redémarrer le service "Exchange Monitoring". Ainsi, la configuration des cmdlets extensions agents sera correctement prise en compte. 

Exchange Monitoring Service

Pour information, ce service peut être redémarré sans incidence.

NB : Il faut redémarrer ce service sur tous les serveurs de l'organisation Exchange car l'opération d'activation/désactivation de l'agent de scripting se fait sur la totalité de ceux-ci.

Exchange 2010 – Problème de mot de passe avec certains Smartphones

Problématique

Sur certains smartphones (BlackBerry et Windows Phone) lors de la connexion à une boite mail Exchange 2010 (via ActiveSync) le mot de passe est demandé alors qu’il est enregistré.

Une resynchronisation de la BAL sans indiquer le mot de passe suffit au smartphone pour se reconnecter.

Contexte

L’architecture en place lors du problème se compose de plusieurs serveurs Exchange 2010 (plusieurs serveurs CAS/HUB, plusieurs MBX en DAG) et de deux serveurs TMG 2010 pour la publication des flux.

Après avoir fait des traces sur TMG, l’erreur suivante est présente à chaque demande de mot de passe :

  • Log Type : Web Proxy (Forward)
  • Status : 10054 An existing connection was forcibly closed by the remote host.

Solution

Le problème provient de TMG. En effet ce dernier possède un timeout sur la session ActiveSync entre le Smartphone et Exchange.

Pour résoudre ce problème il faut changer un paramètre dans TMG. Depuis la console TMG faites un clic droit sur le listener qui publie ActiveSync, ensuite dans Properties, Forms tab, Advanced décochez la case “apply session timeout to non-browser client” (http://technet.microsoft.com/en-us/library/cc995246.aspx).

Exchange 2010–Queue Viewer

En observant les files d’attentes d’un serveur de transport on peut parfois observer une

file en mode “suspended” ne contenant aucun message dont le “delivery type” est

“DnsConnectorDelivery”. La présence de ce type est compréhensible lorsqu’un connecteur

utilise un serveur DNS pour connaitre la passerelle distante, dans mon cas il n’y a que des

connecteurs utilisant une remise vers un “smarthost” !

 

clip_image002

Quoiqu’il en soit supprimons cette file.

Passez la file en mode “resume”. Elle va passer en “ready”:

clip_image002[5]

Redémarrez le service MS Exchange Transport.

Relancez la console Queue Viewer.

clip_image002[7]

La file a disparue.

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.

Exchange 2010 - Liste de distribution

Après avoir créé une liste de distribution vous souhaitez l’ajouter sur une autorisation de

partage d’un dossier public:

image

Vous constatez que la liste ne peut être ajoutée et est marquée du “panneau accès interdit”.

Cela est dû au fait que la liste est du type Mail Universal Distribution group.

image

On doit donc la convertir via la console ADUC ou par une commande powershell

Active Directory :

image

image

Le groupe de distribution est maintenant de type “sécurité”.

Patientons quelques minutes (réplication AD) puis ajoutons l’autorisation

sur le dossier public:

image

Oups, le problème est toujours présent Triste

Vérifions le RecipientTypeDetails

image

Celui-ci est bien du type MailUniversalSecuritygroup !!!

Regardons l’attribut msExchRecipientDisplayType. Celui-ci à la valeur 1.

Ce qui correspond à un “mail universal distribution group”.

La modification réalisée dans l’interface graphique n’a donc pas été prise en compte.

image

Pour corriger le problème il faut utiliser la commande PowerShell Set-DistributionGroup

image

Vous pouvez rencontrer ce type d’erreur, pas de panique Sourire, rajoutez l’option

-MemberDepartRestriction Closed

 

image

Regardons de nouveau l’attribut msExchRecipientDisplayType:

image

La valeur est maintenant 1073741833 ce qui correspond à un “mail universal security group”.

                                                  **************

image

                                          *********************

Essayons de nouveau d’ajouter ce groupe sur les droits du dossier public:

image

Et voilà, mon groupe de distribution est disponible.

A ce jour ce disfonctionnement n’est pas considéré comme “bug” chez Microsoft .