PI Services

Le blog des collaborateurs de PI Services

ADFS / Yammer : Renouvellement des certificats

Introduction

Cet article est un retour d'expérience sur un incident rencontré dans le cadre d'une infrastructure ADFS possédant une fédération avec Yammer. Ce dernier s'est produit lors du renouvellement de certains certificats de l'environnement ADFS. L'authentification unique n'était plus fonctionnelle. En effet, une mise à jour doit être réalisée du côté de Yammer lorsque l'un des certificats ADFS est renouvelé. Pour rappel, contrairement à d'autres services qui peuvent être fédérés (comme Office 365), il n'est pas possible de configurer automatiquement le SSO. Cette opération doit être réalisée via une demande au support Office 365.

 

Dans un premier temps, il sera question de faire quelques rappels sur les certificats ADFS puis d'étudier leurs renouvellements. Enfin, nous verrons comment mettre à jour Yammer pour que le l'authentification ne soit pas indisponible lorsque les certificats sont renouvelés. Ce dernier nous permettra de voir comment gérer les certificats avec des services fédérés qui ne peuvent pas récupérer les métadatas automatiquement.

 

Cette manipulation a été réalisée sur une infrastructure sous Windows 2012 R2 (ADFS 3.0).

 

ADFS

Dans une infrastructure ADFS, 3 certificats sont nécessaires au bon fonctionnement de celle-ci :

  • Un certificat public portant le nom DNS du service de fédération. Il s'agit d'un certificat web permettant de sécuriser les communications via SSL.

  • Un certificat auto-généré de type X.509 permettant de signé les tokens d'authentification (Token-Signing). Celui-ci permet de certifier que le token provient bien de la ferme ADFS.

  • Un certificat auto-généré de type X.509 permettant de décrypter des tokens (Token-Decrypting) provenant d'un autre fournisseur de revendications.

Renouvellement du certificat Service-Communications

Le renouvellement pour le certificat public de type Service-Communications se fait manuellement. Lorsque vous posséder votre nouveau certificat, il est nécessaire de l'importer dans le magasin personnel de l'ordinateur des serveurs ADFS (comme lors de la configuration d'ADFS) et des serveurs Web Application Proxy (si vous en posséder) .

 

Sur les serveurs ADFS, lorsque le certificat est importé, il faut ajouté les permissions de lecture sur la clé privée. Pour réaliser cette opération, il faut effectuer un clic droit sur le certificat (lorsque l'on se trouve dans le magasin personnel de l'ordinateur) puis choisir “All Tasks” puis “Manage Private Keys”.

 

03

 

Dans l'onglet sécurité, il suffit d'ajouter les comptes “NT Service\ADFSSRV” et “NT Service\DRS” (pour la fonctionnalité Workplace Join) puis d'attribuer le droit “Read”. Attention, cette opération est à réaliser sur l'ensemble des serveurs de la ferme ADFS.

 

02

 

Les commande Powershell ci-dessous nous permettent ensuite de mettre à jour la configuration des serveurs ADFS.

 

Sur les serveurs ADFS :

 

On récupère, le certificat en utilisant la commande suivante :

 

Cette dernière permet d'interroger le magasin personnel de l'ordinateur (pensez à remplacer NOM_DNS_FERME_ADFS par le nom de votre ferme de serveurs ADFS). Il est nécessaire de récupérer la valeur de l'attribut thumbprint (Pour rappel, ce champ est unique pour chaque certificat).

 

Ensuite, on modifie la configuration du service ADFS pour utiliser notre nouveau certificat en spécifiant la valeur de l'attribut thumbprint.

 

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

 

Sur chacun des serveurs ADFS d'une ferme, il faut exécuter la commande ci-dessous pour mettre en place le bindings HTTPS avec le nouveau certificat :

 

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

 

Enfin, il est nécessaire de redémarrer le service ADFS sur chacun des serveurs de la ferme.

 

On peut ensuite vérifier les valeurs grâce aux commandes suivantes :

 
 

La seconde cmdlet doit être exécuté sur chacun des serveurs de la ferme ADFS pour effectuer une vérification complète.

 

Les serveurs Web Applications Proxy se mettent à jour via les commandes suivantes :

 
 

NB : Attention, il faut remplacer THUMBPRINT par la valeur obtenu précédemment.

 

Tout d'abord on change le certificat. Dans un second temps, on redémarre le service ADFS pour que le changement de configuration soit pris en compte. Ces deux commandes sont à exécuter sur chacun des serveurs Web Applications Proxy que vous possédez.

 

Renouvellement des certificats Token-Signing et Token-Decrypting

Au sujet, des autres certificats, il existe deux possibilités :

  • Renouvellement manuel

  • Renouvellement automatique

Le renouvellement automatique est la configuration par défaut d'ADFS. 20 jours avant l'expiration d'un certificat, ADFS en génère un nouveau. Celui-ci possède le statut de certificat secondaire. Au bout de 5 jours (soit 15 jours avant l'expiration du certificat), il est promu comme certificat primaire.

 

Les paramètres d'auto renouvèlement se consultent/configurent via Powershell. Pour cela, il faut utiliser la commande “Get-ADFSProperties”. C'est l'attribut AutoCertificateRollover qui permet de déterminer si l'auto renouvèlement des certificats de type Token-Signing et Token-Decrypting est activé.

 

Voici les paramètres ADFS qui peuvent être modifiés par la commande Set-ADFSProperties et qui concernent le mécanisme évoqué précédemment :

  • CertificateDuration : Durée de validité d'un certificat auto généré (par défaut : 365 jours)

  • CertificateGenerationThreshold : Nombre de jours avant la génération d'un nouveau certificat Token Signing or Token Decrypting (par défaut 20).

  • CertficatePromotionThreshold : Nombre de jours avant la promotion du nouveau certificat (passage du status Secondary au status Primary, valeur par défaut : 5 jours).

  • CertificateRolloverInterval : Interval de temps (en minutes) entre chaque vérification de la validité d'un certificat (par défaut 720 minutes).

  • CertificateCriticalThreshold : Nombre de jours avant qu'un certificat expire et qu'un renouvèlement critique ne soit déclenché (ce paramètre intervient lors d'un problème avec le système d'auto renouvellement).

Point d'attention :

Lors du renouvèlement d'un certificat, les métadatas changent. Aussi, si l'un des relying party trust n'est pas capable de récupérer par lui même les métadatas alors l'authentification ne sera plus fonctionnelle.

 

Yammer

La configuration de l'authentification unique via Yammer se fait manuellement. Il est nécessaire d'ouvrir un ticket auprès du support. Celle-ci ne nécessite pas d'envoyer les certificats mais simplement les métadatas. Néanmoins lorsque les certificats ADFS se renouvèlent, il est nécessaire de les transmettre au support Yammer via une demande de service sur le portail d'administration Office 365. Pour se faire, il suffit de créer une archive contenant les nouveaux certificats et de les joindre…

 

Cependant, il peut arriver que le délais soit trop court pour que le ticket soit traité à temps par le support si l'on se trouve presque à la fin de la période de 5 jours après le renouvellement des certificats (voir paragraphe précédent) ou pire, si le nouveau certificat a déjà été défini comme certificat primaire. Ce dernier cas aura pour effet de couper totalement l'authentification unique auprès de Yammer et ainsi causé une coupure de service pour les utilisateurs. En effet, Yammer n'est pas capable de récupérer les nouvelles métadatas contenant les nouvelles informations des certificats.

 

Dans ce cas, on obtient l'erreur ci-dessous lorsque l'on essaie de s'authentifier :

 

01

 

De plus dans l'observateur d'évènements, on remarque des events avec l'id 364 avec pour message :

Lorsque ce problème est rencontré, il faut transmettre le nouveau certificat au support Office 365, ce qui peut peut demander un temps de traitement long. Cependant, si l'ancien certificat est encore valide (c'est à dire qu'il est passé en statut secondaire), il existe une méthode pour rétablir le service temporairement pendant la durée de validité dudit certificat. Pour ce faire, il faut repasser le certificat en statut primaire. Cette opération peut être réalisée via la console graphique.

 

Dans la console ADFS Management, il faut se rendre dans la section “Service” puis “Certificate” puis effectuer un clic droit sur le certificat concerné et choisir l'option “Set as Primary”. Celle-ci peut être grisée. Cela survient lorsque le renouvellement automatique est activé. Il faut donc le désactiver temporairement via la commande suivante :

 

Lorsque le certificat sera de nouveau en statut primaire, le service sera rétabli. Attention, n'oubliez pas de changer le certificat primaire lorsque le support Office 365 vous aura informé de la prise en compte du nouveau certificat.

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.

Office 365 – Retour d’expérience d’une migration IMAP

Introduction

L'offre Office 365 inclut un outil de migration. Cet outil permet la migration des boites mails depuis Exchange (2003 / 2007 / 2010 /2013) vers Office 365 ou depuis un autre serveur de messagerie utilisant l'IMAP vers Office 365.
Ce billet portera sur mon retour d'expérience d'une migration IMAP vers Office 365.

Retour d'expérience

Les prérequis


1) Chaque compte migré doit avoir un utilisateur unique associé avec une licence active. Le compte peut être uniquement dans le cloud ou synchronisé avec Active Directory (via DirSync par exemple).
Dans le cadre d'une architecture hybride (c'était le cas dans ce projet), d'autres prérequis utilisateurs sont nécessaires. L'utilisateur doit être "connu" par les serveurs Exchange OnPremise. Pour cela la commande PowerShell suivante est à passer sur les serveurs Exchange OnPremise :

Enable-RemoteMailbox –Identity Utilisateur –RemoteRoutingAddress utilisateur@tenant.mail.onmicosoft.com –PrimarySMTPAddress utilisateur@domaine.fr
Remarque : Attention, si l'utilisateur possède d'autres adresses SMTP que la principale il est nécessaire de les indiquer dans la commande à l'aide du paramètre EmailAddresses
Remarque 2 : Il est également recommandé d'avoir l'UPN (UserPrincipalName) de l'utilisateur qui soit égal à l'adresse email afin de faciliter la connexion aux services Office 365.

2) Un Migration Endpoint avec les éléments suivants :

  • L'URL du serveur IMAP
  • Le type d'authentification (Basic ou NTLM)
  • Le chiffrement (Aucun, SSL, TLS)
  • Le port utilisé pour se connecter en IMAP au serveur
  • Le nombre maximum de migrations simultanées
  • Le nombre maximum de synchronisation incrémentales simultanées

image
3) Un fichier CSV contenant l'adresse email cible, le nom d'utilisateur et le mot de passe du compte IMAP (ou d'un compte administrateur). Le fichier CSV sera construit ainsi :

Les éléments migrés


La migration IMAP n'inclut que la partie mail. En effet les éléments de type contacts, calendrier, tâches… ne sont pas pris en compte.
La migration IMAP prend en compte les mails qui se trouvent dans les différents dossiers (et sous dossiers) personnels ainsi que les dossiers de base (Boite de réception, éléments envoyés, éléments supprimés…).

La migration


La migration se déroule par lot. Chaque lot peut comporter jusqu'à 5000 utilisateurs.
Pour une meilleure gestion des erreurs et de la volumétrie, des lots de 1200 utilisateurs environ ont été fait.
A titre d'exemple, le temps de migration pour un lot de 1200 utilisateurs ayant une volumétrie d'environ 30 Go au total (soit une moyenne de 25Mo/BAL) a mis un peu plus de deux heures.
Cette estimation est bien évidement propre à l'architecture et peut être différente en fonction de la bande passante et des performances du serveur source.

La gestion des erreurs


Il est courant qu'un lot de migration comporte des erreurs. Pour les identifier il est possible d'utiliser la commande PowerShell suivante sur le tenant Office 365 :
Get-MigrationUser -ResultSize Unlimited | ?{$_.Status -ne "Synced"}

image

Les utilisateurs en échec peuvent être sorti du lot de migration et relancés dans un lot séparé.
Remarque : Un utilisateur ne peut pas être inclus dans un nouveau lot s'il appartient déjà à un lot. Microsoft met également à disposition des rapports (au format CSV) sur la plateforme d'administration d'Office 365 – Exchange.

Conclusion

Dans le cadre de cette migration, le pourcentage d'erreur a été de 0.2% (moins d'une vingtaine de boites en erreur sur plus de 6000 boites migrées).
Le seul point négatif est la limite des éléments migrés. Les calendriers, carnets d'adresses… ne sont pas pris en compte et doivent être fait manuellement par l'utilisateur ou via un autre outil de migration.


Pour conclure l'outil de migration fonctionne parfaitement. Même s'il possède peu de fonctionnalités contrairement à d'autres outils de migration (Refresh IT, Quest…) il permet une migration simple à un moindre coût.

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

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.