Office 365 & Unified Communication

Search Active Conference's Server

Herydis — Thu, 18 Jan 2018 18:26:35 GMT

In some scenarios, you need to troubleshoot problems on a meeting while it is still active. For this need, it can be useful to find the server that hosts this meeting.This script helps you find the server hosting an active conference. For troubleshooting of a particular meeting. The script is available here.

Gérer Meeting Migration Service (MMS)

Herydis — Wed, 16 Aug 2017 02:39:15 GMT

Meeting Migration Service (MMS) est un service de Skype for Business Online qui s’exécute en arrière-plan et effectue automatiquement des mises à jour de réunions Skype pour les utilisateurs. Il dispense l’utilisation de Meeting Migration Tool qui devait être exécuté par chaque utilisateur migré vers Skype for Business Online. MMS s’exécute en cas de migration vers Skype for Business Online et en cas de modification des paramètres de dialin mais nécessite que la boîte de l’utilisateur soit sur Exchange Online. Il ne prend pas en charge les scénarios suivants (utilisez Meeting Migration Tool dans ces cas) :

Migration de Skype for Business Online vers on-premise
Assignation d’un ACP tiers
Boite aux lettre hébergée sur Exchange on-premise

Par défaut, MMS est activé sur tous les tenants Office 365. Pour vérifier l’état du service, utilisez la commande : Get-CsTenantMigrationConfiguration Pour désactiver MMS, exécutez la commande suivante : Set-CsTenantMigrationConfiguration -MeetingMigrationEnabled $false Pour activer ce paramètre, exécutez la commande suivante : Set-CsTenantMigrationConfiguration -MeetingMigrationEnabled $true Pour voir le statut des migrations de meeting lors de vos migrations, utilisez la commande : Get-CsMeetingMigrationStatus -SummaryOnly Pour récupérer le statut des migrations meetings pour un seul utilisateur, utilisez la commande : Get-CsMeetingMigrationStatus -UserId john@contoso.com Vous pouvez récupérer tous les utilisateurs pour lesquels la migration des meetings via MMS a échoué, utilisez la commande : Get-CsMeetingMigrationStatus | Where {$_.State -eq "Failed"} | Format-Table UserId,LastErrorMessage Pour chaque utilisateur de cette liste, vous pouvez soit relancer MMS avec la commande : Start-CsExMeetingMigration -Identity john@contoso.com Pour activer ou désactiver MMS uniquement pour les informations de dialin, utilisez la commande : Set-CsOnlineDialInConferencingTenantSettings -AutomaticallyMigrateUserMeetings $false/$True

Activer DKIM dans Office 365 – Exchange Online

Herydis — Thu, 14 Jan 2016 01:59:23 GMT

Dans l’article précédent – disponible ici, j’expliquais le mode de fonctionnement de DKIM. Dans celui-ci, je présente comment mettre en œuvre (activer) DKIM sur Office 365 – Exchange Online. DKIM est désormais supporté dans Office 365 pour les trafics entrants et sortants. Lorsque votre messagerie est hébergée sous Office 365, vous pouvez envoyer et recevoir des messages chiffrés avec DKIM.

Pour le trafic entrant, vous n’avez rien à configurer. DKIM est activé par défaut dans Exchange Online, tous les messages entrant pourront donc être vérifiés et décryptés. Voici une partie d’entête de mail vers une boite mail Exchange Online.

L’étiquette dkim=none dans l’entête indique que le serveur de réception (Office 365) est capable de déchiffrer DKIM mais le serveur d’envoi n’utilise pas DKIM. Cette étiquette est donc ajoutée à l’entête puis le message délivré.

En ce qui concerne le trafic sortant, vous devez activer DKIM pour chaque domaine SMTP que vous souhaitez. Vous devez récupérer les paramètres suivants de votre domaine : : Il s’agit de la partie précédant votre adresse EOP dont le format est .mail.protection.outlook.com. : votre domaine onmicrosoft.com dont le format est tenant.onmicrosoft.com.

Connectez-vous à Exchange Online PowerShell et exécuter la commande :

New-DkimSigningConfig -DomainName -Enabled $False

Ensuite, récupérez les enregistrements DNS de type CNAME (oui c’est bien CNAME) puis créez les dans votre DNS publique.

Get-DkimSigningConfig | FL domain, *cname

La commande précédente vous donne les valeurs des enregistrements DNS suivants :

selector1._domainkey IN CNAME selector1-._domainkey.
selector2._domainkey IN CNAME selector2-._domainkey.

Créez ces enregistrements sur le DNS publique de votre domaine. Une fois les DNS propagés, exécutez la commande :

Set-DkimSigningConfig -Enabled $True

Voici un exemple d’entête de mail chiffré avec DKIM.

DKIM=Pass indique que le mail a été chiffré à l’envoi et correctement déchiffré à la réception.

Le Spoofing : Une menace quotidienne!

Herydis — Thu, 07 Jan 2016 01:48:58 GMT

Le spoofing (l’usurpation d’identité) est un défi auquel les entreprises doivent faire face de plus en plus. Afin de réduire ce phénomène, plusieurs protocoles et méthodes existent et continuent d’évoluer car les techniques de spam sont en constante évolution. Les méthodes utilisées pour se protéger contre les spams sont les suivantes:

Le SPF (Sender Policy Framework)
Le DKIM (DomainKeys Identified Mail) et
Le DMARC (Domain-based Message Authentication, Reporting and Conformance)

Le SPF a été présenté dans article de Paul Cunningham que je vous invite à lire ici. Je ne présenterai donc plus le SPF en détail. Cet article est dédié à DKIM. DKIM Grace au DKIM, le serveur d’envoi insère une signature numérique dans l'en-tête du message que le serveur de réception doit décrypter afin d’authentifier les sources d’envoi (s’il sait le faire). Il s’agit d’un mécanisme de chiffrement qui permet non seulement d’améliorer la réputation de votre domaine SMTP sur internet mais aussi de limiter l’usurpation de votre identité. Source : Microsoft Comment ça marche : Le SPF (Sender Policy Framework) permet de définir une ou plusieurs adresses IP à partir desquelles les mails de tout domaine peuvent être envoyés. DKIM est nettement plus complexe que SPF en fournissant de manière significative plus de fonctionnalités. Le DKIM utilise le DNS pour publier une clé publique qui sera utilisée par les serveurs de réception pour valider la signature le chiffrement dans les entêtes de mail. À l’envoi d’un mail, le serveur d'envoi calcule une signature cryptographique qui chiffre le message en utilisant une clé privée. La signature est alors placée dans un en-tête de mail. À la réception, la signature du mail est validée à l'aide de la clé publique. Lorsque les serveurs de réception ne sont pas compatibles DKIM, ils ne pourront pas interpreter ou verifier la signature dans les entêtes de mail, ils recevront alors tous les mails même les spams. Les enregistrements DNS pour DKIM Il existe essentiellement deux types d'enregistrements DNS utilisés par DKIM : Les Policy records et les Public key records. Voici un exemple des types de DNS pour DKIM:

Les Policy records

Un nom de domaine utilisant DKIM doit avoir une seule stratégie d’enregistrement (Policy Record) configurée. Il s’agit d’un enregistrement TXT dont le nom contient la chaine de caractères "_domainkey" suivie du nom de domaine. Par exemple, pour le domaine herydis.com, le nom de la Policy record sera "_domainkey.herydis.com". La valeur de cet enregistrement sera au moins ‘’o = -‘’ ou ‘’o = ~’’. ‘’o = -‘’ signifie tous les e-mails provenant de ce domaine sont signés ‘’o =~‘’ signifie certains e-mails provenant de ce domaine sont signés. Ce paramètres peut être combiné en mode test pour une mise en place progressive de DKIM. D’autres paramètres supplémentaires peuvent être ajoutés cette valeur comme (t) pour le mode test, (r) pour adresse e-mail responsable et (n) pour les notes. Le serveur de réception vérifie la Policy Record pour déterminer si le domaine SMTP utilise DKIM. Le cas échéant, le mail est étiqueté comme non-signé.

Les Public key records

Il s’agit de l’enregistrement DNS pour la clé publique DKIM. Le nom de cet enregistrement DNS doit respecter la nomenclature suivante : selector._domainkey.domaine.com. Le sélecteur (selector) : Le sélecteur est une chaîne de caractère arbitraire ajoutée au nom de domaine, pour identifier la clé publique DKIM. Il fait partie de la signature DKIM et est inséré dans le champ DKIM-Signature des entêtes de mail. Le sélecteur permet de définir plusieurs clés publiques par domaine SMTP d’envoi. Un exemple de nom d’enregistrement de public key peut être : paris._domainkey.herydis.com. La valeur doit contenir plusieurs tags séparés par des (;) tels que définis dans la RFC 4871 Section 3.6.1. v= (version) : Optionnel, définit le numéro de version DKIM. La valeur par défaut est DKIM1 car à ce jour il n’existe qu’une version. Exemple : v = DKIM1;. g= (granularité) : Optionnel, permet de définir les adresses/utilisateurs locaux concernés par le chiffrement DKIM. Vous devez définir que le préfixe des adresses concernées. La valeur par défaut est (*). Exemples : Pour une seule adresse mail toto@herydis.com, définir g=toto; Pour plusieurs adresses mail contenant le mot -commerce, définir g=*-commerce; La valeur par défaut correspond à g=*; h= (Algorithme de hash) : Optionnel, contient un ou plusieurs algorithmes de hachage séparés par (:). Les valeurs autorisées sont Sha1 et Sha256. La valeur par défaut est h=*;. k= (key type) : Optionnel, définit le type de clé publique utilisé. La valeur par défaut est k = rsa;. C’est la seule valeur supportée à ce jour. p= (public key) : Définit la clé publique pour l'algorithme défini par le tag (k =) dont la clé privée est utilisée pour signer numériquement les mails. Exemples de clé publiques : Au format ligne unique : paris._domainkey IN TXT "v=DKIM1;p=B7Ijfhepaetnq... AcdEZOIziLdzrr" Au format multi-ligne paris._domainkey IN TXT ("v=DKIM1" "p= B7Ijfhepaetnq... " "zereDSJKZPURUD... " "klzepoqDJKLRER... " " AcdEZOIziLdzrr ") NB : Si la clé utilisée est révoquée, vous devez définir une valeur null pour ce tag (p=;). n= (notes) : Optionnel, avec ce tag, vous pouvez définir un commentaire sur votre clé publique. s= (service type) : Optionnel, il définit le type de service auquel DKIM est appliqué. À cette époque, la seule valeur valide est email mais la valeur par défaut est s = * (All). t= (mode) : Optionnel, par défaut, ce flag n’a aucun paramètre défini. Il peut être accompagné des paramètres (t) et (s). (t) : Indique le mode test. (s) : indique que les sous-domaines ne sont pas pris en compte pour la clé publique DKIM.

SSO avec ADFS 3.0 sur google Chrome

Herydis — Tue, 13 Oct 2015 00:45:55 GMT

Pour offrir à vos utilisateurs, une expérience SSO similaire à Internet Explorer lorsqu'ils utilisent Google Chrome comme navigateur, vous devez ajouter un"UserAgent" à votre configuration ADFS.

Depuis le serveur principal, ouvrir une invite PowerShell et saisir la commande suivante :

Set-ADFSProperties –ExtendedProtectionTokenCheck None

La valeur par défaut est Allow Puis saisir la commande suivante pour obtenir la liste des UserAgent des navigateurs supportés par WIA (Windows Integrated Authentication) :

Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

Comme on peut le constater, il n’y a pas de support pour le UserAgent de Google Chrome, il faut donc l’ajouter à la liste existante. Pour cela, saisir la commande suivante :

Set-ADFSProperties -WIASupportedUserAgents @("MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "Mozilla/5.0")

Vérifier l’ajout du UserAgent de Google Chrome :

Get-ADFSProperties | Select -ExpandProperty WIASupportedUserAgents

En dernier, redémarrer le service ADFS

Office 365 import Service : Cas pratique (Deuxième partie)

Herydis — Thu, 16 Jul 2015 01:43:21 GMT

L’importation des données dans les boîtes aux lettres

Toutes les étapes de préparation étant finies, vous devez créer une tâche d’importation.

Relancez l’assistant d’importation via le réseau

Cocher les options correspondantes aux tâches de préparation

Entrez le nom de la tâche à créer

Téléchargez votre fichier de mappage

Cliquer sur terminer et ensuite, vous pouvez fermer la fenêtre de l’assistant

Vous avez le temps de prendre un café en attendant que la tâche aille au bout. Lorsque l'importation des données est finie, le statut est mis à jour:

Vous pouvez afficher les détails

Office 365 import Service : Cas pratique (Première partie)

Herydis — Wed, 15 Jul 2015 01:37:54 GMT

Dans le cadre de cet article, j’ai décidé d’importer un fichier PST, je vais donc faire une importation à travers mon réseau. L’option 2 comme indiqué dans l’article précédent. L’outil AZCopy:

Vous devez télécharger et installer l’outil d’importation Microsoft Azure AZCopy. Il est disponible ici : https://aka.ms/downloadazcopy Le compte de stockage

Récupérer un compte de stockage : Le compte de stockage vous permettra d’accéder à un espace de stockage pour vos fichiers en attendant d’être importés dans les boîtes aux lettres utilisateurs. Un compte de stockage est caractérisé par une clé et une URL.

Depuis la console Office 365, cliquez sur le lien Importation

Choisissez l’option 2 : Télécharger des fichiers via le réseau

Cliquez sur les liens de page suivante pour obtenir la clé et l’url de stockage

Vous devez conserver la clé et l’URL de stockage en lieu sûr comme vos mots de passe. Le téléchargement des fichiers PST

Pour charger vos fichiers sur les serveurs de Microsoft, utilisez l’outil AzCopy installé précédemment. Il est disponible dans le dossier “C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy”. Il est recommandé de regrouper vos fichiers PST dans un seul dossier partagé. Sinon, vous devrez exécuter l’outil AzCopy pour chaque emplacement contenant vos fichiers.

Exécutez la commande: AzCopy /source:\\SERVER\SHARE /dest:/SERVER/SHARE /destkey: /S /V:C:\temp\upload.log Les différents paramètres : /Source: spécifie le chemin UNC du dossier partagé contenant les fichiers PST à importer. /Dest : Ce paramètre est la concaténation de l’ « URL de stockage » obtenue plus haut et du chemin utilisé en source. Le nom du dossier source doit être ajouté après “ingestiondata/”. /Destkey: Spécifiez la clé de stockage obtenue plus haut. /S : Ce paramètre active la récursivité lors de la copie. Les fichiers inclus dans des sous-dossiers sont également pris en compte. /V : Devant ce paramètre, indiquez d’un fichier pour le processus d’importation Pour plus d’informations sur les différents paramètres de l’outil AzCopy, cliquez sur ce lien https://azure.microsoft.com/fr-fr/documentation/articles/storage-use-azcopy/

Pour être plus concret, votre commande devrait ressembler à celle-ci:

A la fin de l’importation, vous avez un sommaire tel qu’indiqué ci-dessous :

Préparation du fichier CSV de «mapping »

Il s’agit d’un fichier CSV qui permettra d’associer chaque fichier PST importés à une boîte aux lettres Office 365. Le format de ce fichier est :

Important : Vous devez avoir une ligne par fichier PST importé dans Office 365.

Les différentes options du fichier CSV sont : Workload: Dans ce processus, gardez toujours la valeur Exchange FilePath: doit contenir le chemin UNC de vos fichiers PST. Supprimez les ‘\\’ et remplacez les ‘\’ par ‘/’. FileName: Correspond au nom du fichier PST. Mailbox: Indiquez la boîte aux lettres dans laquelle vous souhaitez importer le contenu du fichier pst. IsArchive: Cette option doit contenir les valeurs True ou False. Définissez à ‘True’ pour importer le contenu du pst dans une archive. TargetRootFolder: Définit le dossier de destination des données importées. Si vous ne définissez pas cette options, les éléments seront importés dans un dossier dont le nom par défaut « imported » ou « Eléments importés ». La valeur « / » permet d’importer les données dans le dossier racine de la boîte aux lettres. Pour les options SPFileContainer, SPManifestContainer et SPSiteUrl ne mettez aucune valeur.

Les prérequis du mode hybride Multi-Org

Herydis — Thu, 09 Jul 2015 01:33:07 GMT

Parmi les différents scénarios de migration, le plus confortable pour les grands comptes est le mode hybride. Pour faire une migration en mode hybride, la toute première condition est d’avoir dans votre organisation au moins un serveur Exchange 2010 SP3 ou version ultérieure.

Compte tenu de la taille et de l’historique de l’entreprise, il devient fréquent de rencontrer des environnements avec plusieurs organisations Exchange à migrer vers un même tenant Office 365, Exchange Online. Lorsque les différentes organisations font partie de la même forêt Active Directory, le scénario ne présente pas plus de complexité qu’une migration hybride avec une seule organisation Exchange. Dans le cas d’une migration en mode hybride multi-organisations multi-forêts, vous devez non seulement respecter les prérequis pour une mode hybride simple, mais aussi les prérequis supplémentaires suivants :

Versions de Microsoft Exchange : Dans chaque forêt Active Directory, vous devez avoir au moins un serveur Exchange 2013 SP1 installé. Les rôles CAS et MBX sont tous les deux indispensables pour assurer le trafic entrant et sortant avec Exchange Online Protection.
Synchronisation Active Directory : La synchronisation des comptes Active Directory étant obligatoire pour le mode hybride, vous devez utiliser un outil capable de synchroniser plusieurs forêts. A ce jour, je recommande FIM ou AADSync. Le dernier est plus « simple » d’utilisation et ne nécessite pas d’être dans un domaine Active Directory. Faîtes les bons routages DNS pour qu’il contacte les différentes forêts AD.
Autodiscover et domaine SMTP : Chaque organisation Exchange doit avoir au moins un domaine SMTP principal autoritaire avec la fonctionnalité autodiscover bien configurée. Si plusieurs organisations utilisent le même domaine, vous devez configurer les routages de mails et l’autodiscover avant la mise en place du mode hybride. Office 365 est en mesure d’envoyer des requêtes de découverte automatique sur les différentes organisations.
Certificat : Les certificats de vos organisations ne doivent pas être identiques. Utilisez donc un certificat différent pour chacune de vos organisations impliquées dans votre mode hybride.
SSO/ADFS : La fonctionnalité de SSO fait partie des prérequis lorsque vous mettez en place un mode hybride multi-organisations. Vous devez installer, une ferme ADFS par forêt Active Directory si des relations d’approbations bidirectionnelles n’existent pas entre vos différentes forêts.

Voici un schéma fourni par Microsoft qui illustre très bien le fonctionnement de ce mode hybride :

La gestion des utilisateurs supprimés dans Office 365

Herydis — Thu, 02 Jul 2015 01:28:38 GMT

Lorsque vous supprimez des utilisateurs Office 365, ils sont déplacés et gardés dans le dossier Utilisateurs supprimés pendant 30 jours (délai de rétention par défaut). Pour afficher la liste de tous les utilisateurs supprimés, dont la période de rétention est en cours, utilisez la commande : Get-MsolUser -ReturnDeletedUsers | FL UserPrincipalName Pour rechercher un Utilisateurs en particulier, utilisez la commande : Get-MsolUser –ReturnDeletedUsers –SearchString <UserPrincipalName> | FL UserPrincipalName Pour supprimer definitivement les utilisateurs supprimés sans attendre la fin de la période de rétention, utilisez la commande : Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin –Force

Les stratégies de rétention dans Exchange Online

Herydis — Mon, 18 May 2015 01:24:51 GMT

Cet article a été écrit dans un contexte Office 365 Exchange Online, le principe reste le même lorsque vous avez une organisation Exchange on-premise. Les stratégies de rétention sont l’ensemble des règles mises en place dans le cadre de la conversation/suppression des données de types « mail » au sein d’une entreprise. Les stratégies de rétention font partie du Messaging Records Management (MRM) qui permet aux organisations de gérer le cycle de vie des e-mails et de réduire les risques juridiques liés à l’e-mail et autres moyens de communications. Rappelons que la conversation des données doit se faire dans le but de se conformer à la politique de l'entreprise, aux réglementations gouvernementales, ou des besoins juridiques. La suppression des données, doit se limiter au contenu qui n'ayant pas de valeur légale ou commerciale. Pour plus d’informations, consulter le lien.

Une stratégie de rétention comprend des «Balises de rétention» ayant un type, un critère de sélection, une action et une périodicité. Les balises de rétention peuvent s’appliquer de façon automatique ou manuelle.

Une balise de rétention automatique s’appliquera systématiquement à une boîte aux lettres utilisateur dans son ensemble ou à un dossier spécifique définit, son type est donc Par défaut ou correspond au nom du dossier auquel la balise s’applique. Lorsque la balise de rétention est de type personnel, elle sera appliquée par les utilisateurs à des éléments ou à des dossiers (action manuelle).

Dans Office 365, Exchange Online, une seule stratégie de rétention existe par défaut : Elle est nommée : Default MRM Policy. Elle contient les différentes balises indiquées sur l’image précédente. L’affectation de la stratégie de rétention se fait sur les utilisateurs.

Une fois la stratégie affectée, les balises de type par défaut et par dossier s’appliqueront automatiquement. Les balises de type Personnel seront appliquées par l’utilisateur depuis son client: