PI Services

Le blog des collaborateurs de PI Services

Outlook - Connexion au serveur Exchange indisponible

Contexte

Lors de l'initialisation du client d'Outlook un popup apparaît :

"Impossible de trouver une correspondance pour ce nom. La connexion à Microsoft Exchange n'est pas disponible. Outlook doit être en ligne ou connecté pour effectuer cette action"

Impossible d’aller plus loin. Dans l’observateur des événements l'entrée MAPI : 350569 me dirige vers une impossibilité de contacter le serveur mail.

Solution de contournement

Modifier la base de registre pour spécifier le FQDN du DC où se situe le catalogue global. Créer une nouvelle entrée String Value (REG_SZ) nommer DS Server avec une valeur le nom du serveur.

Il faut redémarrer Outlook et relancer la configuration qui peut  alors se terminer complètement. 

HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider.

 

Le client Outlook n'arrive plus à accéder à la GAL sur Exchange Server 2013

Problème:

Les clients Outlook n'arrivent plus à accéder à la GAL sur Exchange, et donc les utilisateurs sont dans l'incapacité d'ajouter des salles de réunions ou de rechercher contacts qui ne sont pas dans leur cache Outlook. Le client se fige et le message d'erreur suivant apparait après quelques dizaines de secondes:

Troubleshooting:

  • Vérification des journaux d'événements .
  • Vérification de la réplication AD et Exchange.
  • Régénération de l'OAB et MaJ de la GAL. 
  • Déplacement de la boite mail contenant l'OAB vers un autre serveur.
  • Entrée dans le fichier host pour pointer directement sur le serveur hébergeant l'OAB.
  • Test d'accès sur l'URL EWS et l'URL OAB.
  • Vérification des logs IIS.

 

Solution:

Des erreurs 401 étaient retournées depuis le serveur dans les logs IIS. Pour résoudre cette erreur il a fallu redémarrer les services IIS, puis les services "RPC Client Access" et "MS Exchange Throttling", puis de nouveau redémarrer les services IIS.

 

Exchange Online – Erreur avec les listes de distribution dynamiques et le filtre UsageLocation

Contexte

Dans Exchange Online il est possible de créer des listes de distribution dynamiques en se basant sur l’attribut UsageLocation. Cet attribut est défini par l’administrateur lors de l’attribution d’une licence à un utilisateur.

2017-11-21_151051

Cependant lorsque vous créez une liste de distribution il se peut que le filtre ne fonctionne pas et que l’erreur suivante apparaisse lorsque vous tentez de lister les membres de la liste :

2017-11-21_144233

Explications

Lorsque l’on regarde le filtre via la commande Get-DynamicDistributionGroup “dl_language_it” | fl recipientfilter on remarque que la valeur pour l’attribut UsageLocation est en Français. Ceci est causé par le fait que l’outil Microsoft Sign-In Assistant a été installé en Français.

2017-11-21_143648

Même si l’on créé le filtre à l’aide de la norme ISO 3166 (comme décrit dans la KB suivante https://technet.microsoft.com/en-us/library/bb738157(v=exchg.160).aspx), l’outil remplace le code par le texte en Français avant de l’envoyer au serveur Exchange.

Après avoir contacté le support Microsoft, nous avons eu une confirmation de ce problème et une mise à jour doit être apportée dans le code source de l’outil.

Solution

La solution en attendant le fix est de supprimer la liste de distribution et de la recréer depuis une machine où l’outil est installé en anglais. Pour cela, lancez les commandes suivantes :

Remove-DynamicDistributionGroup “dl_language_it”

2017-11-21_144451

New-DynamicDistributionGroup "dl_language_it" -RecipientFilter {UsageLocation –eq “IT”}

La liste des codes ISO pour l’ensemble des pays sont disponibles au lien suivant : https://www.iso.org/obp/ui/fr/

Si l’on vérifie avec la commande Get-DynamicDistributionGroup “dl_language_it” | fl recipientfilter on remarque que l’attribut UsageLocation est maintenant en Anglais.

2017-11-21_144550

Si l’on utilise la commande suivante pour lister les membres, l’erreur n’apparait pas et les membres du groupes apparaissent.

$group = Get-DynamicDistributionGroup ‘”dl_language_it”
Get-Recipient –RecipientPreviewFilter $group.RecipientFilter

2017-11-21_144739

Office 365 migration tenant-to-tenant – Retour d’expérience 1/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant. La première partie traitera de l’architecture et des pré-requis à la migration. La seconde partie traitera du plan d’action et de la migration. Enfin la troisième partie traitera des problèmes rencontrés lors de celle-ci.

Architecture

L’architecture de cette migration est assez simple. Deux environnements similaires contenant chacun Active Directory, Azure AD Connect, ADFS et O365. Le but de la migration est de migrer l’ensemble des données du tenant A vers le tenant B. Les comptes Active Directory ne sont pas migrés et l’ADFS A sera toujours utilisé par les utilisateurs de l’Active Directory A. La synchronisation vers le tenant utilisera bien évidemment le serveur AD Connect B. Enfin les adresses emails garderont le même nom de domaine de la source vers la destination.

Figure 1 – Schéma source de l’architecture

schemaSource

Figure 2 – Schéma cible de l’architecture

schemaCible

Pré-requis

Le premier pré-requis est d’avoir une relation d’approbation inter-forêt entre les deux forêts AD.

La migration tenant-to-tenant nécessite également un outil tiers afin de migrer l’ensemble du contenu des boites aux lettres (emails, contacts, calendrier…).

Un nombre de licences suffisant dans le tenant B est également indispensable pour accueillir les comptes du tenant A.

Enfin il est important d'avoir un compte administrateur global utilisant le domaine par défaut de microsoft (@domaine.onmicrosoft.com).

 

Voilà qui conclut la première partie de mon retour d'expérience. Stay tuned!

Office 365 migration tenant-to-tenant – Retour d’expérience 2/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant.. Voici la seconde partie qui traitera du plan d’action et de la migration.

Plan d’action

Lors de la migration les noms de domaine des adresses emails étant conservés, une coupure de service est obligatoire. Il est donc primordial de bien préparer la migration et d’effectuer en avance de phase toutes les tâches pouvant être traitées pré-migration.

Le plan d’action sera le suivant :

    1. Avoir un export de l’ensemble des données du tenant A. Pour chaque compte connaître son adresse de messagerie, ses alias, ses droits… Idem pour l’ensemble des objets Exchange (boites partagées, listes de distribution, contacts...)
    2. Créer des utilisateurs cloud uniquement dans le tenant B correspondant aux utilisateurs du tenant A. Exemple : john.doe@domainea.com aura un compte john.doe@domaineb.onmicrosoft.com
    3. Assigner des licences aux utilisateurs dans le tenant B
    4. Créer le reste des objets Exchange (attention certains objets peuvent-être synchronisés avec l’AD et d’autre uniquement dans le cloud) du tenant A dans le tenant B
    5. Commencer les migrations via l’outil de migration. Exemple : l’ensemble des mails plus vieux que les 30 derniers jours
    6. Arrêter la synchronisation de l’ensemble des objets de l’Active Directory A vers le tenant A (supprimer la synchronisation des OU dans Azure AD Connect A). L’ensemble des comptes dans le tenant A sont à présent en Soft-Deleted
    7. Utiliser la commande suivante pour restaurer l’ensemble des comptes en tant que comptes cloud uniquement :
      Get-MsolUser –ReturnDeletedUsers –All | Restore-MsolUser
    8. Supprimer l’ensemble des références aux noms de domaine présent sur le tenant A (alias, adresses SIP,…). Tous les objets doivent avoir uniquement des adresses avec l’adresse par défaut de Microsoft
    9. Supprimer les noms de domaine du tenant A
    10. Ajouter les noms de domaine sur le tenant B
    11. Modifier l’UPN des comptes cloud du tenant B pour qu’ils soient égaux aux UPN des comptes de l’Active Directory A.
    12. Créer un nouveau connecteur sur l’AD Connect B pour synchroniser les comptes de l’Active Directory A. Une fois la synchronisation terminée, les comptes cloud du tenant B ont fusionné avec les comptes de l'Active Directory A.
    13. Finaliser la migration via l’outil (attention, les adresses sources et destinations ont changé, il est peut-être nécessaire de les mettre à jour dans l’outil utilisé pour la migration)
    14. Mettre à jour l’ADFS A via les commandes suivantes :
      Set-MsolDomainFederationSettings –domainname "domainea.com" –ActiveLogOnUri "https://<url ADFS A>/adfs/services/trust/2005/usernamemixed" –issuerUri "http://<domainea.com>/adfs/services/trust/" –logoffuri "https://<url ADFS A>/adfs/ls/" –metadataexchangeuri "https://<url ADFS A>/adfs/services/trust/mex" –PassiveLogOnUri "https://<url ADFS A>/adfs/ls/"
      Update-MsolFederatedDomain –DomainName "domainea.com" –SupportMultipleDomain

 

Migration

La planification

La planification de la migration est importante. En effet lorsque l’on se réfère au plan d’action on remarque que beaucoup d’actions sont à faire pendant l’interruption de service (de l’étape 6 à l’étape 12). Il est donc important de bien planifier la migration sur un weekend et de vérifier qu’aucune autre action est prévue à cette date là (paye, bilan comptable…).

Il est également très important de communiquer avec les utilisateurs tout au long du projet. Expliquer pourquoi une telle migration (intégration de la messagerie dans la messagerie groupe par exemple), bien indiquer les dates de la migration, prévenir de l’interruption de service et informer des éléments qui ne sont pas pris en compte par cette migration (signature…).

Y penser !

Une fois la migration terminée, le support utilisateur peut être amener à avoir une surcharge de travail. Avoir une équipe renforcée lors des premiers jours post-migration aidera grandement à la résolution des problèmes et à la gestion du stress des équipes.

Les actions post-migrations

Une fois la migration terminée, certaines actions sont nécessaires côté utilisateur (création d’un nouveau profil sur Outlook par exemple) mais aussi côté administrateur (donner de nouveaux droits d’administration aux équipes sur le tenant B par exemple).

Mettre en place un fichier de suivi pour les problèmes rencontrés est fortement conseillé. Cela permet de centraliser et donc de faciliter la résolution des problèmes et de ne pas oublier certains points (notamment si c’est un problème mineur).

 

Voilà qui conclut la seconde partie de mon retour d'expérience. Stay tuned!

Office 365 migration tenant-to-tenant – Retour d’expérience 3/3

Contexte

Cet article divisé en trois parties est un retour d'expérience sur une migration Office 365 tenant-to-tenant.. Voici la dernière partie qui traitera des problèmes rencontrés lors de la migration.

Problèmes rencontrés et solutions

Eléments de calendrier non-migrés

Un point important pour que la migration des calendrier se fasse, la time-zone de la boite aux lettres de destination doit être renseignée. La commande PowerShell suivante permet de mettre à jour cet attribut

Set-MailboxRegionalConfiguration –Identity "<UserPrincipalName>" –TimeZone "GMT Standard Time"

Les valeurs possibles de la time-zone sont indiqués ici : https://support.microsoft.com/en-us/help/973627/microsoft-time-zone-index-values.

Migration OneDrive

Tout comme la migration des éléments de calendrier, la partie OneDrive nécessite une initialisation des comptes cibles pour que la migration s’effectue.

Lors de cette migration j’ai utilisé le script présent à l’adresse suivante pour initialiser l’ensemble des comptes.

https://support.office.com/fr-fr/article/Comment-configurer-des-sites-utilisateur-dans-OneDrive-entreprise-ceef6623-f54f-404d-8ee3-3ce1e338db07

Mauvaise synchronisation des comptes Active Directory

Au moment de la synchronisation de l’Active Directory A vers le tenant B, il est possible que certains comptes ne fusionnent pas avec leur compte cloud correspondant et que des doublons soient présent.

Il peut y avoir diverses raisons à cela :

  • Une erreur dans l’UPN du compte cloud
  • Un contact déjà présent dans le tenant B avec l’adresse email du compte A
  • Un compte invité dans le tenant B avec l’adresse email du compte A

Dans ce cas, il faut tout d’abord supprimer l’objet (le contact ou le compte invité) du tenant B (en le supprimant également de la corbeille O365). Ensuite il faut désynchroniser le compte AD (en déplaçant le compte dans un OU non-synchronisée). Une fois le compte désynchronisé il faut supprimer ce compte de la corbeille O365. Lancer une nouvelle synchronisation pour que la métaverse de l’AD Connect prenne en compte la modification. Enfin resynchroniser le compte AD. Il doit alors fusionner correctement.

Si ce n’est pas le cas, il est possible que le compte cloud ne récupère par l'attribut ImmutableID. Cet attribut est le "lien" entre le compte dans l'Active Directory (et donc celui de la métaverse AD Connect) et le compte cloud O365.

Pour modifier l'attribut il faut de nouveau désynchroniser le compte AD et le supprimer de la corbeille O365 puis il faut utiliser les commandes PowerShell suivantes.

Sur l’Active Directory A :

$adUser = Get-ADUser "<SamAccountName>" –Properties *

$id= $adUser.ObjectGUID | foreach {[system.convert]::ToBase64String(([GUID]($adUser.ObjectGUID)).tobytearray())}

Sur le tenant B :

Set-MsolUser –UserPrincipalName "<UserPrincipalName>" –ImmutableID $id

Resynchroniser le compte AD.

Conclusion

Ce billet termine mon retour d'expérience sur cette migration tenant-to-tenant. J'espère qu'il vous a été utile.

Compteurs de performance Exchange en erreur

Problème:

Après une installation d'Exchange avec un chemin d'installation différent de celui par défaut, certains compteurs de performance remontent en erreur dans les journaux d'événements.

Solution:

Reconstruire les compteurs de performance à l'aide du script suivant:

 

Add-Pssnapin Microsoft.Exchange.Management.PowerShell.Setup

$Fichiers =get-childitem "E:\Exchange Server\Setup\Perf\" *.xml |where-object {!($_.psiscontainer)}

foreach ($fichier in $fichiers) {

Remove-perfcounters -Definitionfilename $file.fullname

}
foreach ($fichier in $fichiers) {

New-perfcounters -Definitionfilename $file.fullname

}

 

 

Le champ CountryOrRegion génére un filtre OPATH invalide dans une liste de distribution dynamique

Problème:

Impossible de requêter les membres d'un groupe dynamique Exchange ayant un paramètre de filtrage sur le champ "CountryOrRegion".

L'erreur spécifiée est générique et indique que le filtre OPATH ou LDAP est invalide:

"La chaîne de filtre de prévisualisation du destinataire $VotreFiltre n'est ni un filtre OPath valide ni un filtre LDAP valide. Utilisez le paramètre -RecipientPreviewFilter avec une chaîne de filtre OPath valide ou une chaîne de filtre LDAP valide."

Cause:

Une des raisons possible à ce message d'erreur est que la valeur du champ CountryOrRegion ait été déclarée depuis une console Powershell en français (ou toute langue autre que l'anglais). En effet la console powershell interprète et traduit directement la valeur spécifiée pour l'attribut CountryOrRegion.

Par exemple, si vous spécifiez la valeur "CountryOrRegion -eq Germany" ou "CountryOrRegion -eq DE" et que votre console powershell est en français, la valeur retenue et transmise dans le filtre OPATH sera "CountryOrRegion -eq Allemagne".

Ceci est problématique car les serveurs Exchange installés en anglais seront incapables de traduire cette valeur et vous ne pourrez pas interagir avec cette liste de distribution dynamique pour la partie modification et récupération des membres, la liste en elle-même devrait normalement être fonctionnelle. 

Autre raison possible, la valeur n'est pas renseignée correctement.

Les valeurs doivent correspondre à la norme ISO 3166-1 de l'appellation des pays.

https://fr.wikipedia.org/wiki/ISO_3166-1

Solution:

Actuellement, ce problème est considéré comme un fonctionnement standard du produit, pour corriger les listes de distributions dynamiques en erreur, il vous faudra les recréer depuis une console en anglais.

 

 

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.

DirSync – Erreur à l’installation de DirSync sur un serveur Windows Server 2012 R2

La problématique

Lors de l’installation de Windows Azure Active Directory Synchronization (aka “DirSync”) sous Windows Server 2012 R2, l’erreur suivante peut apparaitre :

The minimum version of Windows Powershell required is 2,0.
Please install the minimum version required (or higher) and try again.

image

Cela peut sembler étrange d’autant plus que Windows Server 2012 R2 intègre nativement la version 4.0 de PowerShell.

Explication

Il semble que ce problème soit dû à la localisation du système d’exploitation. En effet sur un système d’exploitation installé en langue française, le caractère séparateur entre les entiers et les décimales est la virgule et non le point.

Or on peut remarque que le message d’erreur indique un problème pour détecter la version PowerShell 2,0 et non 2.0.

Solution

La solution consiste tout simplement à modifier les formats de date, d’heure et de nombre et à les passer sur le format anglais.

image

Il suffit ensuite de fermer, puis de relancer l’installeur de DirSync pour que la modification soit prise en compte et que PowerShell soit bien détecté.

image

N.B. : Ne pas oublier de lancer dirsync.exe avec des droits administrateur (clic droit, puis Run As Administrator), sinon une exception .net apparaît