Maxime Rastello

Device Writeback : activer la synchronisation des devices avec Azure AD Connect

Depuis l’arrivée d’Azure Active Directory, il est possible d’enregistrer des appareils (PCs ou mobiles) via le service Azure Device Registration Service (ou Azure DRS).

Voici les cas où Azure DRS est utilisé :

  • Jonction d’un PC Windows 10 à Azure AD (Azure AD Join)
  • Enregistrement de PCs du domaine AD dans Azure AD (Hybrid Azure AD Join)
  • Enrollment d’un périphérique dans Microsoft Intune

Lorsqu’un périphérique est enregistré dans Azure AD, il apparait comme appareil dans le portail Azure. Cependant dans certains cas, il peut être nécessaire de faire apparaitre dans l’Active Directory local ces appareils enregistrés, notamment pour mettre en place de l’accès conditionnel via Active Directory Federation Services (ADFS 2012 R2 ou ADFS 2016 par exemple).

Voici comment mettre en place le “device writeback” pour couvrir ce scénario :

 

Etape 1 : Préparer la forêt AD pour le device writeback

Pour permettre la synchronisation des devices joints à Azure Active Directory (smartphones inscrits dans Intune, devices Windows 10), il est nécessaire de préparer la forêt Active Directory locale.

Prérequis Active Directory :

  • Compte Enterprise Admin de la forêt Active Directory
  • Au moins un catalogue global present dans la forêt
  • Schéma de la forêt en Windows Server 2012 R2 (ou supérieur)

Deux cas sont possibles :

Cas 1 : Vous avez déjà activé Device Registration Services

Si vous avez déjà active la fonctionnalité Device Registration Service incluse dans ADFS 2012 R2, vous n’avez pas besoin de préparer votre forêt Active Directory : en effet, la commande Initialize-ADDeviceRegistration a déjà créé le containeur dédié dans votre annuaire local. Vous devrez toutefois effectuer l’étape 3 si vous possédez des devices Windows 10.

Pour information, le conteneur utilisé se situe dans CN=Device Registration Configuration,CN=Services,CN=Configuration. Vous pouvez y accéder avec ADSI Edit.

 

device registration service conteneur

 

Les devices synchronisés seront quant à eux presents dans le conteneur CN=RegisteredDevices à la racine de votre domaine AD.

 

registered devices adsi

 

Cas 2 : Vous n’avez pas activé Device Registration Service

Si vous n’avez pas ou ne souhaitez pas activer Device Registration Service, Microsoft a mis en place un module PowerShell afin de créer ce conteneur sans activer l’intégralité du service sur l’ADFS.

Prérequis sur le serveur exécutant le script :

  • Module Active Directory PowerShell
  • Module Azure Active Directory PowerShell (+ Microsoft Online Services Sign-in Assistant)
  • Binaires du rôle Active Directory Domain Services installés (pour avoir l’outil dsacls.exe)

Récupération du script PowerShell

Pour effectuer la préparation de la forêt Active Directory, il est nécessaire de récupérer un module PowerShell présent sur le serveur Azure AD Connect et de l’exécuter sur le serveur possédant les prérequis ci-dessus

  1. Se connecter au serveur Azure AD Connect
  2. Aller dans le dossier C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep et récupérer le module AdSyncPrep.psm1

Exécution du script PowerShell

  1. Lancer une console PowerShell avec un compte ayant les permissions Enterprise Administrator
  2. Aller dans le dossier contenant le module PowerShell AdSyncPrep.psm1
  3. Exécuter la commande Import-Module .\AdSyncPrep.psm1
  4. Exécutez les commandes suivantes :
Initialize-ADSyncDeviceWriteBack -DomainName votredomaine.com -AdConnectorAccount "<comptedeserviceAADConnect>"

 

Remplacez “<comptedeserviceAADConnect>” par le nom du compte de service utilisé pour installer Azure AD Connect. Si vous avez utilisé les paramètres Express, le compte de service créé automatiquement commence par “MSOL_xxxxxxxx”.

 

Etape 2 : Configurer Azure AD Connect

Lors de la configuration de l’outil Azure AD Connect, vous devez tout d’abord activer la fonctionnalité de Device Writeback.

 

enable device writeback

 

 

Etape 3 : Préparer la forêt AD pour les devices Windows 10

Une étape supplémentaire est nécessaire cette fois pour supporter la synchro des périphériques Windows 10 joints à Azure AD. Si vous ne possédez aucun device Windows 10, vous pouvez ignorer cette dernière étape.

Vous aurez besoin pour cette étape de récupérer le nom du compte Active Directory créé durant l’installation d’Azure AD Connect. Ce compte se situe dans le conteneur “Users” de votre annuaire :

 

msol account azure ad connect

 

Suivez le pas-à-pas du Cas 2 pour importer le module ADSyncPrep.psm1, puis exécutez les commandes suivantes :

$AzureAdminCredential = Get-Credential -Message "Entrez vos identifiants Administrateur Azure Active Directory"
Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount "MSOL_XXXXXXXXXX" -AzureADCredentials $AzureAdminCredential

Migrer DirSync ou Azure AD Sync vers Azure AD Connect

Depuis le 24/06/2015, Azure Active Directory Connect est disponible en version finale. Pour plus d’informations entre les versions DirSync, Azure AD Sync et Azure AD Connect, je vous recommande de livre mon precedent article : DirSync vs Azure AD Sync vs Azure AD Connect : lequel choisir ?

Pour télécharger Azure Active Directory Connect, cliquez ici !

 

dirsync upgrade to azure ad connect

 

Chemins de migration

Voici un tableau récapticulant les possibilités de migration d’un outil de synchronisation à un autre :

 

Légende :

  • Réinstallation par-dessus via le Wizard : il n’est pas necessaire de désinstaller l’ancienne version de l’outil pour passer à la suivante. Lancez simplement le nouvel exécutable et l’assistant d’installation devrait migrer vos paramètres de manière transparente. Cette migration s’appelle une migration “In-place”.
  • Export de la configuration et migration sur un nouveau serveur en utilisant le Wizard : il est nécessaire d’exporter manuellement la configuration pour la réimporter dans AADConnect. AADConnect doit donc être installé sur un nouveau serveur. Cette migrations’appelle une migration “side-by-side”.
  • Bloqué : ce scénario n’est pas supporté et une résinstallation par-dessus sera bloquée par l’assistant. Il convient de désinstaller l’ancien outil puis d’installer le nouveau : une reconfiguration des paramètres est à prévoir (OU, règles personnalisées…).

 

DirSync, Azure AD Sync, Azure AD Connect : lequel choisir ?

Dernière MàJ : 07/12/2016

Si vous travaillez sur un projet Office 365 ou Azure, vous avez forcément du entendre parler de la synchronisation des identités dans Azure Active Directory. Avant de se lancer dans la synchronisation de votre annuaire Active Directory dans le cloud, vous devrez choisir avec soin le bon outil de synchronisation.

Pour y voir plus clair, je vous propose de faire le point ensemble sur les différents outils à votre disposition, ainsi que leurs différences fondamentales.

  1. Directory Sync
  2. Azure AD Sync
  3. Azure AD Connect
  4. Chemins de migration

Directory Sync tool (DirSync)

Update 06/2016 : DirSync ne sera plus supporté à partir du 13 Avril 2017

Cet outil possède en fait bien des noms ! Certains l’appelent DirSync, d’autres Azure Directory Sync ou encore Office 365 DirSync et j’en passe… Historiquement, DirSync est le tout premier outil de synchronisation des identités dans le cloud.

De nombreuses personnes utilisent encore le terme DirSync pour désigner de manière générique l’outil de synchronisation vers Azure, je vous conseille cependant de toujours utiliser le bon nom pour éviter toute confusion.

Important : DirSync n’est plus proposé en téléchargement.

Historique des versions

Fonctionnalités

* possible en changeant les paramètres des connecteurs, mais non supporté par Microsoft

Note : Il n’est pas possible de mettre en place une mode Exchange hybride multi-forêt avec cet outil.

On-premises > Cloud

Cloud > On-premises

 

Azure Active Directory Sync (AADSync)

Update 06/2016 : Azure AD Sync ne sera plus supporté à partir du 13 Avril 2017

Azure Active Directory Sync est le remplaçant de DirSync. Toujours basé sur le moteur de Forefront Identity Manager 2010 R12 (FIM), il introduit des nouveautés majeures : le support du password write-back et de la synchronisation multi-forêt. L’édition et la création de nouvelles règles de synchronisation est déportée dans une nouvelle interface : Synchronization Rules Editor.

Dans cette mouture, seul Active Directory est supporté en tant qu’annuaire source.

Important : Azure AD Sync n’est plus proposé en téléchargement.

Historique des versions

Fonctionnalités

Note : Il n’est pas possible de mettre en place une mode Exchange hybride multi-forêt avec cet outil.

On-premises > Cloud

Cloud > On-premises

* nécessite une licence Azure Active Directory Premium (P1 ou P2)

 

Azure Active Directory Connect (AADConnect)

Azure Active Directory Connect est le remplaçant d’Azure AD Sync. AADConnect introduit une nouvelle interface de configuration permettant de mieux guider les administrateurs dans la mise en place de leur synchronisation. Il est désormais possible de choisir entre la synchronisation des mots de passe ou la mise en place d’une infrastructure ADFS/ADFS Proxy. Le programme va ensuite piloter le déploiement de ces rôles.

AADConnect est pour l’instant en version Preview, et n’est pas supporté dans un environnement de production (sauf pour les clients membres du programme TAP).

Update 24/06/2015 : Azure AD Connect est désormais disponible en GA

Important : Azure AD Connect est désormais le seul outil de synchronisation fourni par Microsoft.

Historique des versions

Fonctionnalités

Note : Il n’est pas possible de mettre en place une mode Exchange hybride multi-forêt avec cet outil.

On-premises > Cloud

Cloud > On-premises

* nécessite une licence Azure Active Directory Premium (P1 ou P2)

 

Chemins de migration

Voici un tableau récapitulant les possibilités de migration d’un outil de synchronisation à un autre :

 

Légende :

  • Réinstallation par-dessus via le Wizard : il n’est pas necessaire de désinstaller l’ancienne version de l’outil pour passer à la suivante. Lancez simplement le nouvel exécutable et l’assistant d’installation devrait migrer vos paramètres de manière transparente. Cette migration s’appelle une migration “In-place”.
  • Export de la configuration et migration sur un nouveau serveur en utilisant le Wizard : il est nécessaire d’exporter manuellement la configuration pour la réimporter dans AADConnect. AADConnect doit donc être installé sur un nouveau serveur. Cette migration s’appelle une migration “side-by-side”.
  • Bloqué : ce scénario n’est pas supporté, et une réinstallation par-dessus sera bloquée par l’assistant. Il convient de désinstaller l’ancien outil puis d’installer le nouveau : une reconfiguration des paramètres est à prévoir (OU, règles personnalisées…).

Lync Android et ADFS 2012 R2 : impossible de se connecter à Lync Online (we can’t sign you in)

Depuis Windows Server 2012 R2, ADFS et Web Application Proxy utilisent une fonctionnalité du protocole SSL/TLS : Server Name Indication (SNI). SNI permet d’inclure dans le header de la demande le hostname du serveur auquel il essaye d’établir une négociation TLS. Cela est notamment très utile afin d’utiliser plusieurs hostnames et plusieurs certificats SSL différents dans IIS sur une même interface réseau.

Cependant, certains clients ne supportent pas encore cette nouvelle fonctionnalité, et c’est le cas des clients :

  • Lync 2010 pour Android
  • Lync 2013 pour Android
  • Lync sous Windows Phone 7.8

Symptômes

Vous essayez de vous connecter à Lync Online au travers d’un compte fédéré via ADFS 3.0 sous Windows Server 2012 R2. Vous obtenez le message “We can’t sign you in. Please try again” sous Lync 2013 pour Android.

 

lync can't sign you in

 

Résolution

Les clients Lync Android et Windows Phone 7.8 n’étant pas compatibles avec SNI, vous devrez effectuer une manipulation sur vos serveurs ADFS internes et Web Application Proxy afin de rajouter un binding dédié.

Sur vos serveurs ADFS internes

  1. Ouvrez une invite de commande cmd en tant qu’administrateur
  2. Tapez la commande netsh http show sslcert pour afficher la liste des bindings configurés par ADFS
  3. Repérez et copiez quelque part les valeurs Certificate Hash et Application ID du binding lié à votre service ADFS (dans mon cas : adfs.home.maximerastello.com)

      

    netsh bindings sslcert

      

  4. Tapez la commande netsh http add sslcert ipport=0.0.0.0:443 certhash=<votre hash> appid={votre app id} en remplaçant par les valeurs notées à l’étape 3
  5. Redémarrez le service Active Directory Federation Services

Note : pour le service ADFS 2012 R2, l’app ID est censé être {5d89a20c-beab-4389-9447-324788eb944a}

 

netsh bindings sslcert 2

 

Important : N’oubliez pas de répéter cette opération sur tous les serveurs de votre ferme ADFS

Sur vos serveurs Web Application Proxy

Effectuez la même opération que sur les serveurs ADFS internes sur tous les serveurs WAP de votre ferme, et n’oubliez pas de redémarrer à chaque fois les services suivants :

  • Active Directory Federation Services
  • Web Application Proxy Controller Service

 

Vous êtes désormais en mesure de vous connecter à Lync Online via le client Android.

Désinstaller correctement Azure AD Connect Preview

Un bug a été détecté dans Azure AD Connect Preview, empêchant la désinstallation complète du produit.

En effet, lorsque vous souhaitez désinstaller le programme via Programs and Features, la désinstallation de Microsoft Azure Active Directory Connect Tool (Preview) ne désinstalle pas automatiquement l’outil de synchronisation Microsoft Azure AD Sync.

 

Uninstall AADConnect Preview

 

Il vous sera donc impossible de réinstaller correctement l’outil, et un nettoyage manuel sera nécessaire. Microsoft est au courant de ce problème et doit le corriger pour la sortie officielle du produit.

Solution

Nous n’avez pas encore désinstallé Azure AD Connect (ouf)

La solution de contournement consiste à désinstaller d’abord Microsoft Azure AD Sync AVANT de désinstaller Azure AD Connect Preview.

Pour cela :

  1. Ouvrez une Invite de Commande en tant qu’administrateur
  2. Tapez la commande cd “C:\Program Files\Microsoft Azure Active Directory Connect”
  3. Tapez ensuite la commande DirectorySyncTool.exe /uninstall

      

    Command Prompt

     

  4. Dans la fenêtre qui s’affiche, cliquez sur le bouton Uninstall

      

    AADConnect uninstall

     

  5. Vous pouvez maintenant désinstaller l’outil Azure Active Directory Connect Tool (Preview) depuis le menu Program and Features

 

Vous avez déjà désinstallé Azure AD Connect (zut)

Vous allez devoir effectuer un nettoyage du serveur pour pouvoir réinstaller correctement l’outil AADConnect.

Suivez ce guide pour plus d’informations.

Azure AD Sync : Unable to install the Synchronization Service

Lorsque vous essayez de supprimer l’outil Azure Active Directory Sync, il se peut que la désinstallation ne se passe pas correctement, soit parce que vous n’avez pas désinstallé le bon produit dans le menu Programs and Features, soit parce que l’installation est corrompue.

Dans ces cas-là, l’erreur suivante peut s’afficher dans l’assistant Azure Active Directory : « Unable to install the Synchronization Service. PLease see the event log for additional details« .

 

unable to install the synchronization service

 

Voici quelques pistes pour désinstaller manuellement Azure Active Directory Sync.

Désinstallation des produits

Dans le menu Programs and Features, désinstallez tous les produits suivants :

Avec Azure Active Directory Connect

  • Microsoft Azure Active Directory Connect Tool
  • Microsoft Azure AD Sync
  • Forefront Identity Manager Windows Azure Active Directory Connector
  • Microsoft SQL Server 2012 Express LocalDB
  • Microsoft SQL Server 2012 Native Client
  • Microsoft SQL Server 2012 Command Line Utilities
  • Microsoft Online Services Sign-in Assistant (redémarrage requis)
  • Windows Azure Active Directory Module for Windows Powershell

 

<img class=" size-full wp-image-2921 aligncenter" src="http://www.maximerastello atorvastatin generic.com/wp-content/uploads/2015/01/uninstall-programs.png” alt=”uninstall programs” width=”534″ height=”309″ srcset=”http://www.maximerastello.com/wp-content/uploads/2015/01/uninstall-programs.png 534w, http://www.maximerastello.com/wp-content/uploads/2015/01/uninstall-programs-300×174.png 300w” sizes=”(max-width: 534px) 100vw, 534px” />

 

Avec Azure Active Directory Sync (standalone)

  • Microsoft Azure AD Connection Tool
  • Microsoft Azure AD Sync
  • Forefront Identity Manager Windows Azure Active Directory Connector
  • Microsoft SQL Server 2012 Express LocalDB
  • Microsoft SQL Server 2012 Native Client
  • Microsoft SQL Server 2012 Command Line Utilities
  • Microsoft Online Services Sign-in Assistant (redémarrage requis)
  • Windows Azure Active Directory Module for Windows Powershell

Suppression des dossiers

L’assistant de désinstallation ne supprime pas certains dossiers, ce qui peut poser des problèmes lors d’une réinstallation.

Vous devez donc supprimer les dossiers suivants :

Avec Azure Active Directory Connect

  • C:\Program Files\Microsoft Azure Active Directory Connect
  • C:\Program Files\Microsoft Azure AD Sync

 

Azure AD Sync folders

 

Avec Azure Active Directory Sync (standalone)

  • C:\Program Files\Microsoft Azure AD Connection Tool
  • C:\Program Files\Microsoft Azure AD Sync

 

Suppression de la tâche planifiée

Vous devez également supprimer la tâche planifiée lancant la synchronisation des objets dans le Cloud.

  1. Ouvrez le Task Scheduler
  2. Dans le conteneur Task Scheduler Library, faites un clic-droit sur Azure AD Sync Scheduler et cliquez sur Delete

 

task scheduler azure ad

 

Nettoyage du registre

Ouvrez le registre en tant qu’administrateur et supprimez les clés suivantes si elles existent encore :

Avec Azure Active Directory Connect

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AD Sync
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Azure AD Connect
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server Local DB
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\MicrosoftAzureADConnectionTool
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ADSync
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\AzureActiveDirectoryDirectorySyncTool
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\AzureADConnect_RASAPI32
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\AzureADConnect_RASMANCS
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\DirectorySyncTool_RASAPI32
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\DirectorySyncTool_RASMANCS

 

Avec Azure Active Directory Sync (standalone)

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AD Sync
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server Local DB
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSOLCoExistence
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\MicrosoftAzureADConnectionTool
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ADSync
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\AzureActiveDirectoryDirectorySyncTool
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\DirectorySyncTool_RASAPI32
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\DirectorySyncTool_RASMANCS

 

Vous pouvez désormais relancer l’installation d’Azure Active Directory Connect.

ADFS 3.0 Windows Server 2012 R2 : erreur 1297 lors du démarrage du service ADFS

Lorsque vous installez Active Directory Federation Services 3.0 (ADFS) sur un serveur Windows Server 2012 R2, il se peut que vous rencontriez l’erreur suivante :

Windows could not start the Active Directory Federation Services service on Local Computer.

Error 1297 : A privilege that the service requires to function properly does not exist in the service account configuration.

 

erreur 1297 service adfs 3.0

 

Solution

L’erreur affichée dans l’Event Viewer est pour une fois claire : il manque un privilège au service ADFS pour qu’il puisse se lancer correctement.

Un petit tour dans le registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\adfssrv nous montre que le service a besoin du privilège Security Audits.

 

ADFS service privilege security audit

 

Il ne vous reste plus qu’à rajouter votre compte de service ADFS dans la partie “Generate Security Audits” des paramètres de sécurité locaux, ou de déployer ce paramètre par GPO.

 

security audit ADFS GPO

 

Pour information, ce paramètre se situe dans la partie Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.

AADSync 1.0.0419.0911 : l’attribut ProxyAddresses ne se synchronise pas

Edit 27/10/2014 : Microsoft a désormais publié une mise à jour de l’outil AADSync en version 1.0.0470.1023. Cette dernière mouture corrige enfin le problème de synchronisation des proxyAddresses. Vous pouvez la télécharger ici.

———————————————————–

AADSync (Microsoft Azure Active Directory Sync) est le nouvel outil de synchronisation d’annuaires vers Office365 et Azure. Cette release a été publiée le 15/09/2014 en version 1.0.0419.0911.

AADsync est toujours basé sur le moteur FIM, mais un certain nombre de nouveautés ont été introduites :

  • Nouvelle interface de configuration
  • Synchronisation multi-forêt
  • Synchronisation de plusieurs serveurs Exchange on-prem vers un même tenant Office365
  • Gestion des synchronisations dans le Task Scheduler
  • Nouvelles règles de filtrage, de mapping d’attributs AD et de provisionning (Synchronization Rules Editor)
  • Nouvelles commandes Powershell

AADSync et ProxyAddresses : attention

Après avoir désinstallé DirSync puis installé AADSync, j’ai eu la surprise de voir que tous mes alias de messagerie Exchange Online avaient disparu sur l’ensemble de mes boites mails.

Un petit tour sur les forums montre effectivement une réponse de la part du Support Microsoft : la version 1.0.0419.0911 ne prend pas correctement en charge le mapping de l’attribut ProxyAddresses. Ce n’est pas tout à fait vrai. En fait, cela dépend de votre configuration.

Voici la mienne :

  • Pas d’organisation Exchange interne
  • J’ai choisi l’option Users are only represented once across all forests
  • Je gère manuellement la liste des proxyAddresses dans les comptes AD
  • Password Write-back : désactivé
  • Mapping / Filtering : activé pour toutes les applications

Le champ mailNickName de mes comptes Active Directory n’est par contre pas renseigné, et c’est à ce niveau que ça coince. En effet, un certain nombre de filtres sont appliqués par défaut sur les règles préexistantes.

La règle In from AD – User Common from Exchange prend en charge l’attribut ProxyAddresses mais n’est appliquée que si le champ MailNickname n’est pas nul.

 

mail nickname

Solution de contournement

La solution de contournement est simple : Soit vous complétez le champ mailNickName de tous vos comptes AD, soit vous créez une nouvelle règle de Transformation dans Synchronization Rules Editor.

  • Ouvrez l’outil Synchronization Rules Editor.
  • Dans la partie Rules Type, choisissez Inbound.

 

Synchronization Rules Editor

 

  • Sélectionnez la règle In from AD – User Common et cliquez sur Edit.

 

Synchronization Rules Editor - Inbound rule

 

  • Dans l’onglet Transformations, cliquez sur Add Transformation puis sélectionnez ProxyAddresses dans la partie Target et Source. Enregistrez les modifications en cliquant sur Save.

 

transform rule aadsync

 

  • Allez dans le dossier C:\Program Files\Microsoft Azure AD Sync\Bin puis lancez DirectorySyncClientCmd.exe pour lancer une nouvelle synchronisation.

 

  • Ouvrez la console FIM (C:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exe) et vérifiez que vos alias de messagerie ont bien été synchronisés dans le cloud !

 

FIM Proxy Addresses

Azure Active Directory Sync : erreur Windows Powershell 2.0 (DirSync)

Lorsque vous souhaitez installer l’outil Azure Active Directory Sync (DirSync) sur une machine Windows Server 2008 R2 en français, vous pouvez rencontrer l’erreur suivante :

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

 

Erreur Powershell Dirsync

 

Cependant, vous n’êtes pas sans savoir que Windows Server 2008 R2 est livré avec… Powershell 2.0 ! Vous ne devriez donc pas rencontrer cette erreur sur un serveur 2008 R2 ou supérieur.

 

Solution

Cette erreur est due à une mauvaise gestion du format régional par l’outil d’installation DirSync. En effet, le programme d’installation est incompatible avec le format régional français, qui a comme symbole décimal la virgule, au lieu du point aux Etats-Unis. Le problème est connu de Microsoft et sera corrigé dans la prochaine version de l’outil.

Pour pouvoir installer DirSync, vous devez donc changer temporairement le format régional de votre serveur en Anglais (Etats-Unis) le temps de l’installation.

 

Format régional Windows

 

Alernativement, vous pouvez également changer le symbole décimal en cliquant sur le bouton Paramètres supplémentaires.

 

Symbole décimal Windows

Workplace Join : échec de rattachement erreur 0x80180008

Lorsque vous essayez de rattacher un PC Windows 8.1 au Workplace Join de l’entreprise, vous pouvez rencontrer l’erreur suivante :

Vérifiez que les informations de connexion que vous utilisez sont correctes et que votre lieu de travail utilise cette fonctionnalité. Il est possible que la connexion au réseau de votre lieu de travail ne fonctionne pas pour l’instant. Réessayez ultérieurement.

 

Erreur Workplace Join

 

L’analyse des journaux d’événements indique l’erreur suivante :

Echec de l’opération de rattachement à l’espace de travail. Code de sortie : 0x80180008

 

Event ID Workplace Join

 

Solution

Ce message d’erreur indique que le certificat public utilisé pour le Web Application Proxy ne contient pas le SAN enterpriseregistration.<votredomaine>.

D’après la documentation officielle TechNet, devez en effet utiliser un certificat contenant :

  • <nom du service de federation>.<votredomaine>
    Par exemple adfs.maximerastello.com
  • enterpriseregistration.<votredomaine>
    Par exemple enterpriseregistration.maximerastello.com

Mais qu’en est-il des certificats wildcard ?

Attention aux certificats wildcard !

Workplace Join nécessite la création d’un SAN enterpriseregistration même si vous utilisez un certificat de type wildcard (*). Ce fonctionnement est “by-design” et ne peut être modifié (pour l’instant du moins).

Par exemple, le certificat wildcard suivant n’est pas utilisable pour Workplace Join car il ne contient pas un SAN enterpriseregistration.

 

Certificat Wildcard Workplace Join