Il peut arriver que lors d’un double-clic sur un fichier xls/xlsx, Excel s’ouvre mais sans ouvrir le fichier demandé.
Pour corriger ceci, aller dans Fichier -> Options -> Options avancées -> Géneral (vers le bas de la liste)
et décocher
Ignorer les autres applications qui utilisent l'échange dynamique de données
Pour Outlook 2016 et + .
Identifier le nom du profil concerné (ici nom-du-profil ) et du compte mail concerné. Fermer Outlook.
Ouvrir regedit.
Atteindre HKCU\Software\Microsoft\Office\16.0\Outlook\Profiles\nom-du-profil
Rechercher la chaîne 001f6641
Examiner les résultats dans l’ordre ; faire un double-clic sur l’entrée (de type REG_BINARY) pour en voir le contenu, et chercher celle qui contient l’adresse mail à supprimer. Il y en au sûrement plusieurs, la 1e occurence devrait être ok.
Une fois la valeur trouvée, on peut supprimer (ou renommer) l’ensemble de la clé qui la contient.
On devrait alors pouvoir supprimer le compte en question.
Dans le cas d’une synchronisation d’un AD local vers Azure Active Directory (AAD), il peut arriver d’avoir une incohérence dans les adresses mail d’un utilisateur entre l’AD local, le Office Admin Center (OAC) et le Exchange Admin Center (EAC).
Par exemple, supposons que
mondomaine.ville.entreprise.fr . Ce domaine n’est pas routable sur internet. Nous avons en plus un domaine monentreprise.com qui est routable sur internet et est le domaine utilisé pour les adresses mailmonentreprise.com a bien été ajouté comme UPN dans le domaine localentreprise.onmicrosoft.com chez Microsoft 365, et ajouté/validé le domaine monentreprise.com sur M365Dans le cas où, en local, dans “Utilisateurs et Ordinateurs AD” (ADUC), le “Nom d’ouverture de session de l’utilisateur” (UPN) est “@mondomaine.ville.entreprise.fr”, alors l’utilisateur apparaîtra comme “@entreprise.onmicrosoft.com” dans l’OAC et dans l’EAC. Les mails envoyés arriveront via la même adresse “onmicrosoft”. L’adresse “@monentreprise.com” apparaît normalement comme un alias, et les mails envoyés à cette adresse sont bien reçus.
Si on modifie le nom d’ouverture de session en “@monentreprise.com”, après synchronisation (et délai de qqs minutes), l’adresse sera modifiée dans l’OAC.
Selon les cas, l’adresse peut également être modifiée dans l’EAC, mais pas systématiquement. Dans le cas où elle reste en “onmicrosoft”, c’est que l’attribut “mail” en local (ADUC) est manquant.
Si on ajoute l’attribut “mail” et lui donnant la valeur “@monentreprise.com”, après synchronisation (et délai), alors elle sera bien mise à jour dans l’EAC, et les mails envoyés auront l’adresse correcte.
Il y’a 2 types de compte Microsoft : les comptes personnels (créé et géré par soi-même) et les comptes professionnels/scolaires (créés par une organisation pour une personne de l’organisation).
Il est parfois pas évident de distinguer si nous utilisons un compte personnel ou professionnel. Voici des URL qui ne semblent fonctionner que pour 1 seul des 2 types :
PRO
https://myaccount.microsoft.com
(renverra sur microsoftonline.com ; refusera un login personnel)
PERSO
https://login.live.com
(annonce que le compte n’existe pas si on essaye un compte pro)
https://admin.microsoft.com, https://login.microsoft.com , https://account.microsoft.com ou https://login.microsoftonline.com` redirige vers un des 2 “logins” ci-dessus, selon le type de compte.
Il me semble que l’on peut établir une équivalence entre l’usage de l’URL “live.com” et un compte personnel : l’un implique forcément l’autre.
(en fait non : c’est le cas pour strictement https://login.live.com, mais la même URL avec des paramètres peut accepter un compte pro en redirigeant vers login.microsoftonline.com ).
Liens VLSC
https://www.microsoft.com/Licensing/servicecenter/default.aspx
https://www.microsoft.com/fr-fr/licensing/default
https://www.microsoft.com/fr-fr/microsoft-365/enterprise/microsoft-office-volume-licensing-suites-comparison
Pour créer un compte d’admin d’entreprise “.onmicrosoft.com”, il est nécessaire de passer par l’achat d’une licence orientée pro (par exemple Office 365 Business Standard) ; on peut toutefois utiliser l’offre 1 mois gratuite.
Le domaine sera créé via une adresse mail externe en guise d’administrateur. Nécessite une carte bancaire.
Il est déjà arrivé quue la connexion d’Office à un compte personnel, dans le but d’activer le produit, ne se fasse pas, Office essayant de se connecter à un compte pro.
En ce cas, utiliser le Store pour se connecter a fonctionné, et la connexion à Office a ensuite récupéré la connexion établie vers le compte personnel. Il est ensuite possible de se déconnecter du store.
Il peut parfois être nécessaire de reconfigurer complètement les services de synchronisation entre un Active Directory local et les services Office 365 (Azure Active Directory Connect).
Pour ceci, il faut les désactiver chez O365 via Powershell, les désinstaller du serveur local, puis réinstaller AAD Connect sur le serveur local.
On ouvre une session Powershell en admin.
Si les outils de gestion PS vers O365 ne sont pas installés, on le fait via
Install-Module -Name MSonline
(si message de commande introuvable, il est nécessaire d’installer les PackageManagement, dispo ici
On initialise la variable de connection via
$msolcred = get-credential
en rentrant les ids d’un admin sur O365.
On établit la connection aux services O365
connect-msolservice -credential $msolcred
Il est ensuite temps de supprimer les applis AAD Connect du serveur local (ajout/suppression de programme).
Une fois désinstallés, on lance la commande PS :
Set-MsolDirSyncEnabled -EnableDirSync $false
et on valide avec Y.
pour obtenir l’état de synchro, on lance la commande
Set-MsolDirSyncEnabled -EnableDirSync $false
qui doit désormais renvoyer “false”.
Il faut plusieurs heures (voire une nuit) à Microsoft Azure pour prendre réellement en compte l’arrêt de la synchro. Lorsque ce sera fait, l’interface d’admin O365 n’affichera plus le status AAD Connect, ni l’état (Synchronisé/Dans le cloud) des Utilisateurs O365. Les utilisateurs anciennement synchronisés seront de facto considérés comme utilisateurs cloud.
Une fois que la suppression de la synchro est bien prise en compte par les serveurs O365, il suffit de réinstaller Azure AD Connect, avec éventuellement une passe préalable de IdFix.
Cf. ce post
La synchro reprend normalement assez rapidement, et quelques heure plus tard, l’état AAD Connect réapparait dans le centre d’administration O365.
Globalement, l’autorisation “Gérer” de AD correspond au status “Propriétaire” sous O365.
Ce qui existe dans l’AD est transmis vers O365/EAC, l’inverse n’est pas (forcément) vrai. Si on souhaite avoir les éléments en local, il FAUT les créer en local.
Les autorisations d’envoyer un mail “en tant que” (par ex. en tant qu’un groupe de distribution) se gèrent dans tous les cas dans l’EAC, car dans le setup actuel, il n’y a pas de serveur Exchange en local, seulement sur O365.
Un utilisateur créé sous AD apparaîtra dans O365 sous “Utilisateurs actifs” et dans EAC sous “Destinataires -> Boîtes aux lettres”. C’est un utilisateur à part entière avec boîte mail dédiée.
Un groupe de sécurité créé sous AD peut avoir une adresse mail renseignée ou non.
Si adresse, il apparaîtra dans O365 sous “Groupes” (en tant que “Sécurité avec extension messagerie”) et dans EAC sous “Destinataires -> Groupes” (en tant que “Sécurité à extension courrier”).
Si aucune adresse mail n’est renseignée, il apparaitra sous O365 sous “Groupes” (en tant que “Sécurité”) et n’apparaitra PAS dans EAC.
C’est avant tout un groupe pour l’organisation de l’entreprise (GPO de l’AD, etc.), qui peut également être utilisé pour remettre un courrier à tous les membres de ce groupe.
Si un autre groupe est lui-même membre du groupe, les utilisateurs de cet autre groupe ne recevront le mail QUE SI cet autre groupe a une adresse de messagerie renseignée dans ses propriétés (ceci permet de couper le transfert vers les N+1 par exemple, si on ne met pas d’adresse mail).
Un groupe de distribution créé sous AD apparaitra dans O365 sous “Groupes” en tant que “Liste de distribution” et dans EAC sous “Destinataires -> Groupes” en tant que Liste de distribution. Il faut lui définir une adresse mail, sans quoi son intérêt est très limité (il semble qu’il n’apparaisse as dans EAC si pas d’adresse mail renseignée).
C’est un alias qui va rediriger le courrier envoyé à l’adresse en question vers tous les membres inclus dedans (permet une gestion différente des groupes de sécurité).
Si un sous-groupe est lui-même membre du groupe, les utilisateurs de ce sous-groupe ne recevront le mail QUE SI le sous-groupe a une adresse de messagerie renseignée dans ses propriétés.
L’autorisation “Send As” ne peut être définie que directement dans le EAC. Par contre, si le groupe a été créé sur AD, l’autorisation “Send On Behalf” est définie dans ADSI, sous l’attribut “publicDelegates”. Il faut toujours attendre quelques (dizaines de) minutes pour que les changements soient effectifs sous Exchange.
Dans certains cas, le client Outlook d’un utilisateur peut rester “bloqué” sur l’intention d’envoyer “de la part de” (on behalf), ce qui echouera si la seule autorisation accordée est “send as”. Pour “réinitialiser” le comportement du client, il faut désactiver puis réactiver le mode “en cache” du compte Exchange.
Il s’agit d’une boîte à part entière, avec son propre stockage/quota (quota de 99Go à l’heure de cet article). Elle permet de centraliser des messages partagés par plusieurs utilisateurs, ainsi que le calendrier. Sur l’Outlook de l’utilisateur, la boîte sera distincte de celle de l’utilisateur.
Elle permet également de partager un calendrier entre tous les utilisteurs.
Comme nous n’avons dans le cas présent pas de serveur Exchange en local, il ne me semble pas possible d’en créer une sur l’AD. Elle peut être créée dans l’EAC sous “Destinataires -> Boîte aux lettres partagée”.
Elle n’apparaitra pas dans l’AD, mais dans O365 sous les “Utilisateurs actifs”, et bien sûr dans l’EAC.
Dans le centre d’administration Exchange (EAC), on peut aller dans Recipients -> Shared, et créer une boite aux lettres partagées. Tous les utilisateurs qui sont entrés dans les propriétés de la boite partagée -> Mailbox delegation -> Full access verront la boite mail ainsi que son calendrier se déployer automatiquement sur leur client Outlook (avec toutefois un délai jusqu’à une heure).
Ceci correspond à une vraie boîte mail à part entière, avec son propre espace de stockage (quota de 99Go à l’heure de cet article) et apparaitra sur le client outlook séparée de la boite principale.
Il semblerait que l’ajout d’un groupe de sécurité, même avec adresse mail renseignée, ne déploie pas automatiquement les boites et calendriers chez les membres du groupe.
Dans le EAC -> Recipients -> Groups, on peut créer des listes de distributions. Ceci ne correspond pas à une vraie boîte mail, mais plutôt à un alias. Les messages sont transférés à tous les utilisateurs définis dans les propriétés de la liste -> Membership.
Si on souhaite qu’un utilisateur puisse écrire depuis l’adresse de la liste de distribution, il faut ajouter l’utilisateur en question dans les propriétés de la liste -> Group delegation, et ajouter son nom sous Send As (envoi en tant qu’alias) ou bien Send on Behalf (envoi en tant que user au nom de alias).
Pour que l’utilisateur puisse envoyer des messages depuis sont Outlook (version de bureau), il faut ajouter le champ De qui est masqué par défaut. Sous 2016, ceci peut se faire dans la fenêtre de rédaction d’un message, sous l’onglet Options. Ensuite, on ajoute à la main le nom de l’alias qui doit servir à envoyer le message. Si les paramètres serveur sont corrects, l’envoi devrait fonctionner. Sinon, essayer de désactiver puis réactiver le mode “en cache” du compte Exchange.
Dans mon cas, l’AD avait été pis en place il y’a longtemps, le domaine local était du genre domain.oldcompany.com, mais les utilsateurs utilisaient aujourd’hui des adresses mail du genre user@newcompany.fr, et l’abonnement O365 avait pour domaine initial unusedcompany.onmicrosoft.com.
Dans ces conditions, la synchro de l’AD vers Azure donnait des identifiants du type nomprenom@unusedcompany.onmicrosoft.com, ce qui rend tout plus pénible, par exemple la connexion à OWA qui ne marche pas avec d’éventuels alias, mais qu’avec cet identifiant.
Comme le domaine initial ne peut être changé, il faut ajouter et vérifier le domaine newcompany.fr dans la gestion des domaines sur le portail O365, connecté en admin de l’abonnement. Pour le vérifier, il faudra aller mettre une preuve TXT dans la zone DNS.
Il faut ensuite ajouter un nouveau suffixe UPN au domaine (Outils d’administration -> Domaines et approbations Active Directory -> Propriétés -> Suffixes UPN), on ajoutera ici newcompany.fr car c’est l’adresse couramment utilisée par l’entreprise. Il faut ensuite modifier les suffixes UPN des utilisateurs dans les Utilisateurs et Ordinateurs AD, pour les passer de p.nom@domaine.oldcompany.fr à p.nom@newcompany.fr. Il est possible de le faire en PowerSehll, par exemple avec ce script
Ainsi, les utilisateurs auront un seul couple adresse/password pour se connecter à tout (Session sur le domaine, OWA, Portail O365 pour télécharger les logiciels etc).
Pour synchroniser un Active Directory local avec les services Azure Active Directory, il faut commencer par préparer l’AD local (notamment étendre le schéma AD sur un serveur Windows 2012). Cette page de Microsoft détaille beaucoup plus la précédure.
Il faut récupérer une installation d’Exchange 2013, par exemple sur cette page de chez Microsoft. On la décompresse, on lance cmd puis la commande suivante :
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Une fois que le schéma est préparé, on peut identifier les incohérences dans l’annuaire avant de synchroniser avec O365. Pour ça, on utilise l’outil IdFix (DL). Dans le cas où une offre dediée à O365 a été souscrite, il faut aller dans les paramétres et choisir “Dedicated” au lieu de “Multi-tenants”. On clique sur Query, on le laisse chercher, on vérifie puis acccepte les modifications, on fait Apply et on voit ce que ça donne. Si tout va bien, on peut passer à la synchro avec Azure. Si il y’a des problèmes (par exemple attributs non-existants), revérifier que l’AD a bien été préparé tel qu’indiqué sur le tuto de Microsoft.
Télécharger AAD Connect. La dernière version à prendre en charge Windows Server 2012 R2 est la 1.6.16.
Synchronisation du hachage de mot de passe.
Utilisé l’UPN (userPrincipalName) comme nom d’utilisateur AAD.
Pour installer le module :
Import-Module ADSync
ou si ça ne fonctionne pas :
Import-Module -Name "C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync" -Verbose
Une fois installé et configuré, il est possible de synchroniser manuellement avec la commande PowerShell :
start-adsyncsynccycle -policytype delta
Envoi en tant que groupe :
Set-distributionGroup -Identity "group" -GrantSendOnBeHalfto "user@domain.com"