Office Servers and Services

"La connaissance ne vaut que si elle est partagée" / "An effective Knowledge is a shared one"

TEAMS: MailUser & Guest Access

Posted by Teruin laurent sur décembre 12, 2018


The purpose of this post is to present the problems of incompatibility between certain types of objects present in the Office 365 environment and Teams’ external access

In the example below, we have an Active Directory LT01.LOC forest with an Exchange 2010 environment in hybrid mode. The Active Directory forest is synchronized with the Office 365 Tenant.

In the forest in question we have created several types of objects which are as follows

  • An email contact created in Exchange 1010 with the following SMTP address :LT01MAILCONTACT01@EXAKIS.COM
  • A user with an email user extension (Mail user) with the following SMTP address :LT01MAILUSER@EXAKIS.COM
  • A simple Active Directory user with an email address on his account:LT01USER01@EXAKIS.COM

Now let’s see how teams will react when we try to invite these people into a channel


These three objects are obviously synchronized via azure AD connect

Test of the contact email

The contact is well synchronized in the azure AD environment, Teams will consider him as an external person, great !


Mail user test

Although the user does not have mailboxes in our environment, the fact that he is registered as a user with mail user extension in the Exchange 2010 environment means that teams finds this entry and considers him as an internal person


Test of a simple AD user with the mail field filled in

In the case of an simple Active Directory user who is synchronized in the Office 365 environment and in the case where the mail field is filled in with his external address, then teams considers him as an internal person


 Conclusion

If you have user accounts with email extension (especially for your subcontractors) and you need to grant them external access via their email addresses then you will need to either license them on your tenant or not use the Mail user object type.

You will need to

1.    Delete their mail user account
2.    Created a simple Active Directory user without entering his email address if you want to synchronize it (I don’t see the point since the objective is not to assign licenses to him…) or enter his email address in the AD field but not synchronize it.
3.    Create a mail contact with its external address to make it appear in the global address list of Microsoft Exchange Online and to be able to include it in distribution lists

Sincerely
Laurent TERUIN

 


 

Publicités

Posted in Non classé | Leave a Comment »

Teams : Prise en charge de l’adhésion Dynamique dans les Groupes 0365

Posted by Teruin laurent sur décembre 11, 2018


Microsoft a annoncé que Microsoft Teams prend désormais en charge les équipes connectées aux groupes Office 365 avec une adhésion dynamique.

L’adhésion dynamique réduit l’administratifs concernant la gestion des membres et permet de s’assurer que les bonnes personnes sont toujours impliquées. L’adhésion dynamique fonctionne en utilisant un ensemble défini de règles qui recherchent certains attributs utilisateur dans Azure Active Directory. Une équipe peut être ajoutée à un groupe Office 365 existant avec une adhésion dynamique, ou l’adhésion d’une équipe existante peut être définie sur dynamique.

Cordialement

Laurent Teruin

Posted in Non classé | Leave a Comment »

Teams: 4 nouveaux Rôles d’administration

Posted by Teruin laurent sur décembre 11, 2018


Microsoft apporte quatre nouveaux rôles d’administrateur dans Teams. Cette mise à jour est disponible dans votre centre d’administration Microsoft 365 aujourd’hui.

Les rôles d’administrateur de Microsoft 365 correspondent aux fonctions d’entreprise courantes et donnent aux membres de votre organisation les autorisations nécessaires pour effectuer des tâches spécifiques dans le centre d’administration de Microsoft 365.

Microsoft a créé quatre nouveaux rôles spécifiquement pour les administrateurs responsables des équipes Microsoft. Ces nouveaux rôles sont :

Service d’administration des équipes : Peut gérer tous les aspects des équipes Microsoft sauf l’attribution des licences. Cela comprend les politiques d’appel, de messagerie et de réunions, l’utilisation d’outils d’analyse des appels pour dépanner les problèmes de téléphonie et la gestion des utilisateurs et de leurs paramètres téléphoniques. Ils peuvent également gérer des groupes Office 365.

Administration des communications des équipes : Peut gérer les fonctions d’appel et de réunion des équipes Microsoft, y compris l’attribution des numéros de téléphone et les politiques de réunion. Ils peuvent également utiliser des outils d’analyse des appels pour dépanner les problèmes.

– Ingénieur support communication d’équipes : Peut dépanner les problèmes de communication au sein des équipes à l’aide d’outils d’analyse d’appels et peut afficher les informations complètes des enregistrements d’appels pour tous les participants impliqués.

Spécialiste du support à la communication des équipes : Peut dépanner les problèmes de communication dans les équipes à l’aide d’outils d’analyse des appels et peut afficher les informations d’enregistrement des appels pour l’utilisateur spécifique recherché. Ces nouveaux rôles d’administrateur sont maintenant disponibles pour être assignés dans votre centre d’administration Microsoft 365 ou en utilisant PowerShell. Ces mises à jour ne sont pas actuellement disponibles pour les organisations GCC.

Cordialement

Posted in Non classé | Leave a Comment »

TEAMS: Accès invité, Mail User Mail Contact & Utilisateur AD

Posted by Teruin laurent sur décembre 11, 2018


Le but de ce post de présenter les problèmes d’incompatibilité entre certains types d’objets présents dans l’environnement Office 365 et l’accès externe de Teams

Dans l’exemple présenté ci-dessous, nous avons une forêt Active Directory LT01.LOC comprenant un environnement Exchange 2010 en mode hybride.

La forêt Active Directory est synchronisée avec le tenant Office 365.

Dans la forêt en question nous avons créé plusieurs types d’objets qui sont les suivants

  • Un contact mail créé dans Exchange 1010 avec l’adresse SMTP suivante :LT01MAILCONTACT01@EXAKIS.COM
  • Un utilisateur avec extension de messagerie (Mail user) avec l’adresse SMTP suivante :LT01MAILUSER@EXAKIS.COM
  • Un simple utilisateur Active Directory avec une adresse mail renseignée sur son compte :LT01USER01@EXAKIS.COM

Maintenant voyons comment teams va réagir lorsqu’on va tenter d’inviter ces personnes dans un channel

Ces trois objets bien évidemment synchronisés via azure AD connect

Test du mail contact

Le contact est bien synchronisé dans l’environnement azure AD, Teams va le considérer comme quelqu’un d’externe, dirons-nous à juste titre

Test du mail user

Bien que l’utilisateur ne possède pas de boîtes aux lettres dans notre environnement le fait qu’il soit déclaré en tant que utilisateur avec extension de messagerie (mail user)dans l’environnement Exchange 2010, fait que teams trouve cette entrée et le considère comme quelqu’un d’interne


Test d’un simple utilisateur AD avec le champ mail renseigné

Dans le cas d’un utilisateur Active Directory qui est synchronisé dans l’environnement Office 365 et dans le cas où le champ mail est renseigné avec son adresse externe, alors teams le considère comme quelqu’un interne

 

Conclusion

Si vous avez des comptes utilisateurs avec extension de messagerie (notamment pour vos sous-traitants) et que vous devez leur accorder un accès externe via leurs adresses de messagerie alors vous devrez soit leur accorder une licence sur votre tenant, soit ne pas utiliser le type d’objet Mail user.

Vous devrez

  1. Supprimer leur compte mail user
  2. Créé un simple utilisateur Active Directory sans renseigner son mail si vous désirez le synchroniser (je n’en vois pas l’intérêt vu que l’objectif est de ne pas lui attribuer des licences..) soit renseigner son email dans le champ AD mais ne pas le synchroniser.
  3. Créez un Mail contact avec son adresse Externe pour le faire apparaitre dans la liste d’adresse globale de Microsoft Exchange Online et pour pouvoir l’inclure dans des listes de distribution

Cordialement

Laurent TERUIN

 

 

 

 

 

 

Posted in Non classé | Leave a Comment »

Améliorations sur la migration des dossiers publics

Posted by Teruin laurent sur décembre 10, 2018


Microsoft a travaillé dur en coulisse pour améliorer la migration des dossiers publics et annonce quelques améliorations. Ces améliorations vous aideront à intégrer plus rapidement les dossiers publics à Exchange Online.

Amélioration de la vitesse

Mailbox Replication Service (MRS) effectue certaines tâches de nettoyage pendant la phase de finalisation de la migration. Si une tâche de nettoyage échoue, elle est réessayée pendant 4 heures au maximum. En fin de compte, cela retardera la finalisation de la demande de migration. Et le retard sera encore plus grand s’il y a un plus grand nombre de jobs de migration dans le lot.
Ils ont apporté des améliorations aux tâches de nettoyage qui ont lieu lors de la finalisation de la migration des dossiers publics. Après ces améliorations, ils ont observé que les migrations de dossiers publics de grande taille, qui, historiquement, auraient pu prendre 3 à 4 jours, sont réalisées en seulement 15 à 20 heures.

Amélioration de la fiabilité

Auparavant, si un lot de migration rencontrait un avertissement non fatal, un avertissement qui pouvait être ignoré, il était toujours marqué Failed. Dans de tels scénarios, un administrateur du tenant devrait soumettre à nouveau le lot de migration, ce qui pourrait entraîner des retards importants dans la migration.

Ils ont apporté des améliorations dans ce domaine. Si le lot de migration se termine avec ces mêmes avertissements non fatals, le lot est traité comme terminé avec succès. Cela permet d’accélérer la migration des dossiers publics, sans compromettre l’intégrité des données. Ces améliorations sont en cours de déploiement sur Exchange Online et devraient être mises à la disposition de votre tenant sous peu.

Posted in Non classé | Leave a Comment »

Without Identity, there is no migration project

Posted by Teruin laurent sur décembre 10, 2018


When merging or acquiring companies, the question of information systems integration arises. In most cases, several scenarios are possible. The most logical but sometimes the most complicated is the merger, the second, generally faster integration, consists in interconnecting this information system via mutual approvals between the different environments. In both cases, it will be necessary, at some point, to establish a cohabitation, a coexistence of systems that will quickly allow users of acquired subsidiaries to access the group’s business applications.

Generally, this coexistence is not an objective in itself, but rather a transitional step that allows sales forces and business managers to integrate the group’s applications directly. This coexistence will then have to give way to a real merger, which may eventually include the removal of the new subsidiary’s information system. The objective in this case is to obtain, through a single directory, homogeneous services for the group (messaging, intranet, collaborative portals, telephony, etc.). In addition to Data Migration, the question of identities will then arise. Without Identity, there is no migration project.

In the Microsoft environment, the company’s technical directory is represented by the Active Directory. When acquiring new companies, the question arises of integrating all its users, their workstations, their servers but sometimes their Office 365 environment into the group’s infrastructures. The first project to be addressed is undoubtedly identity. How many user accounts are to be taken over? How are subcontractor accounts managed, what is the identity management policy in the new subsidiary?

Without the definition of the merger or identity integration project, other services will not be able to migrate. This is the first project that will have to be addressed. This is precisely what we propose you to study

Possible scenarios

There are actually 2 main scenarios that can be considered when a company acquisition occurs.

Integration: The first scenario, known as integration, assumes that the environment of this new society will continue. In this case, the directory identities will have to be kept and synchronized to Azure AD if the group has an Office 365 environment. The establishment of approval relationships between its two environments will make it possible to easily share resources, via mono or bidirectional authentication processes. This scenario can of course be repeated, allowing new acquisitions to quickly integrate the group’s resources. This is sometimes the case when the acquired company retains its own identity or brands. In this case, integration is simple, users keep their own identity, their email address, their instant messaging ID etc… etc… etc…

From an architectural point of view, the two forests coexist on both sides with domain controller servers deployed in each respective agency. It should be noted in passing that this mode of operation may, however, raise some mobility concerns when a group user tries to connect from a subsidiary’s network.

In our case, directory synchronization processes such as Azure Ad Connect to Office 365 support these scenarios, and are perfectly adapted to these situations.

Despite this, and despite this relative simplicity, adaptations are often desirable and undertaken, such as the homogenization of email addresses, the standardization of resource naming as meeting rooms, distribution lists, security groups can be. The objective is then to offer users a single and homogeneous directory in which they can find their way and address resources between the various entities.

This integration can also be improved if both companies have messaging systems based on the same technologies such as Microsoft Exchange. In this case, so-called « rich » interactions are possible, such as being able to search the busy free slots of employees located in another subsidiary. More simply, if the group has chosen Microsoft Exchange Online messaging, with the subsidiary’s identities synchronized, it will then be quite simple to migrate the subsidiary’s messaging data to this new environment.

In this scenario, the group’s Identity and Access Management (IAM) processes will also be updated. They will have to take this new environment into account a posteriori, and be able to address it when new identities have to be created or deleted. This generally involves bringing this new directory up to group standards, by « populating » in particular unique identifiers (Personnel numbers, Identifier) on objects such as user accounts, subcontractor accounts, etc… Here again, the objective is not to eliminate the subsidiary’s directory but to integrate it into the group’s identity management processes.

Merger: The second scenario, which we will call a merger, consists in considering that the directory of the acquired subsidiary has the objective of disappearing. Only user data will be included, and the identities specific to the subsidiary environment will therefore have to be ignored in the synchronization processes. In most cases, all users as well as their workstations and server resources (to name a few) will have to migrate to the group’s Active Directory environment.

This scenario is obviously more complex and longer, but the integration in the long term will be more successful. Everyone will be integrated into the Group’s one and only Active Directory forest.In this case, the question is how to achieve this identity fusion, while integrating the migration of the related data. Again, without an identity, there is no migration project. How can you integrate the data of a new company into the Office 365 & Active Directory environment of a group, without synchronizing your directory data, knowing that data and access are closely linked?

The first thing to do is to create these same identities in the destination environment (Group environment) and synchronize them if necessary, in the Office 365 environment. A common key will have to be established between the two directory environments to ensure that a one-to-one relationship for user accounts in particular can be established. Users will have two accounts, one in their original forest, one in the group’s forest.

In most cases, the creation of these new identities is based on the group’s current standards, so it is not uncommon for the login names to be different for the subsidiary. If the group uses Office 365, the user’s login name (UPN) will generally be identical to their main email address (@agency.com for example), which will force the subsidiary in the event of two-way approval relationships to no longer use it for the benefit of the group directory. (Deletion of the UPN in the source forest in case of a bidirectional approval relationship).

For reasons of access to the agencies’ resources, the creation of these user accounts will also have to take into account their old identity and more particularly what is known as the Sid History. This Sid History will allow users who need to use their identity within the group to continue to have access to their old resources such as file services.

As the agency directory must disappear, and therefore must not be synchronized around 0365, it will also be necessary to recreate all the inherited security and distribution groups to the group directory, taking care here too to keep their Sid History (Security Group only). Most companies often use this opportunity to rename them so that they follow the current nomenclature (this is called directory data transposition rather than duplication). As the fusion scenario is a process that will last, until all workstations integrate the new forest, this transposition will have to be maintained to allow resources to move to these new identities.

Once this transposition is implemented and maintained, the displacement of resources can take place. The latter will have to rely on and take into account this identity transposition to modify the inherited authorizations and replace them with the group’s identities. This is what migration tools generally do by integrating as Sharegate an identity mapping table as part of the migration of Sharepoint resources whether they are hosted on site or on 0365. (Migration Tenant à Tenant)

Once migrated, users connected with their accounts in the group’s forest will find their accesses on their Sharepoint sites.

For mailbox & public folder migration, if the subsidiary uses the Exchange environment, the migration is more complex and would deserve a thorough publication. However, by duplicating the email attributes of users in the Source environment to the destination forest, you should be aware that it is possible to move mailboxes from the subsidiary to the group environment by attaching these mailboxes to group identities. This mailbox movement having as a particularity the preservation of the Mailbox Guid attribute, it will allow the automatic update of your users’ Outlook profile, avoiding you an intervention on each workstation.

Identity, as we have tried to demonstrate to you, often underestimated, therefore plays a decisive role in integration projects and, depending on the level of complexity, can call into question your migration strategy. Analyzing how these mergers, adaptations and the consequences of their modifications on the application environment will be carried out is essential to build a realistic project plan. This should be one of the first steps to be taken into account. Without an identity, there is no migration.

Regards

Laurent TERUIN

Posted in Non classé | Leave a Comment »

IGNITE 2018 : Contenu des principales sessions

Posted by Teruin laurent sur octobre 26, 2018


Bonjour

Vous trouverez ci joint le contenu des principales sessions classé par theme. Il y a « un peu » de lecture pour vos longues soirées d’automne

https://1drv.ms/f/s!AlKfEdbwpIS_heIEZiJydl2j0LZ6GA

Cordialement

PS : Si vous voulez récupérer l’intégralité de toutes les sessions je vous conseille d’utiliser ce script https://gallery.technet.microsoft.com/Ignite-2016-Slidedeck-and-296df316

 

 

Posted in Non classé | Leave a Comment »

Microsoft Exchange : Controller l’accès aux dossiers publics

Posted by Teruin laurent sur octobre 22, 2018


Jusqu’à présent, les administrateurs n’avaient aucun contrôle sur les utilisateurs qui pouvaient parcourir les dossiers publics depuis leurs clients Outlook. Si des dossiers publics ont été créés au sein de l’organisation ou si une organisation Exchange Online est configurée pour accéder à des dossiers publics sur site, tous les clients se connecte et afficher l’objet « Dossiers publics » dans Outlook. De là, les administrateurs pouvaient contrôler l’accès aux dossiers publics individuels (contrôlé par les permissions des dossiers). Cependant, il était très difficile de restreindre l’accès aux dossiers publics.

Microsoft introduit désormais la possibilité de contrôler l’affichage l’objet du dossier public dans Outlook à un seul ensemble d’utilisateurs qui pourraient en avoir besoin.

Pour ce faire, les administrateurs peuvent utiliser deux paramètres :

  • PublicFolderClientAccess est un paramètre facultatif sur l’objet utilisateur. Par défaut, sa valeur est fixée à ‘false’. Si vous définissez ce paramètre sur  » true  » pour un utilisateur spécifique, cet utilisateur sera désigné comme l’un des utilisateurs qui verront les dossiers publics dans Outlook.
  • PublicFolderShowClientControl dans la configuration de l’organisation. Par défaut, la valeur de ce paramètre est également ‘false’ et une fois qu’il est réglé sur’true’, l’accès contrôlé des dossiers publics est activé.

Voici un exemple d’utilisation de ces paramètres ; pour n’autoriser l’accès qu’à l’utilisateur « Administrateur » et activer la fonction pour l’organisation :

set-CASMailbox « Administrator » -PublicFolderClientAccess $true
Set-OrganizationConfig -PublicFolderShowClientControl $true

Remarque importante : régler le paramètre d’organisation sur true sans régler les attributs utilisateur sur true en premier fera en sorte qu’aucun utilisateur ne verra l’objet du dossier public dans Outlook pour Windows. En d’autres termes, si vous voulez implémenter ceci, nous vous suggérons de planifier à l’avance et de remplir d’abord les attributs utilisateur (PublicFolderClientAccess sur les utilisateurs qui ont besoin d’accès défini sur true) puis de définir le paramètre du niveau organisation (PublicFolderShowClientControl défini sur true). De cette façon, les utilisateurs qui ont besoin d’avoir accès ne perdront pas l’accès de façon inattendue.

Les administrateurs du Tenant disposeront désormais d’une plus grande flexibilité quant aux utilisateurs qui se connectent aux dossiers publics dans Outlook. Cela profitera aux très grandes organisations qui pourraient avoir des problèmes avec les limites de connexion aux dossiers publics et réduira la charge de cette infrastructure.

 

.

Posted in Non classé | Leave a Comment »

Exchange Online : Empêcher l’authentification Basique

Posted by Teruin laurent sur octobre 15, 2018


Les équipes de Microsoft vont introduire sur Exchange Online une nouvelle fonctionnalité qui sera le fait de pouvoir disposer d’une Politique d’authentification. Les stratégies d’authentification fourniront à l’administrateur la capacité de définir des protocoles qui devraient permettre, ou pas, l’authentification de base. Les politiques pourront être créées et définies par défaut pour le Tenant, ou définies par utilisateur, Les paramètres par utilisateur remplaçant les paramètres par défaut du Tenant. Lorsqu’une connexion à Exchange Online via l’authentification de base est établie, les conditions de la police sont vérifiées et appliquées. Si la tentative de connexion a utilisé l’authentification de base et que la stratégie est configurée pour empêcher la connexion de base, la connexion sera bloquée à ce point.

Pour rappel l’authentification basiques est utilisée par tout les clients non microsoft comme les clients de messagerie présent par defaut dans les clients Android. Cette Authentication de base transmet le mot de passe en clair dans un Tunnel crypté HTTPS.

Laurent TERUIN

 

 

Posted in Non classé | Leave a Comment »

0365: When one feature chases another / Team Guest Access VS MailUser

Posted by Teruin laurent sur octobre 11, 2018


Hello.

Some time ago we had identified that if people (Mail user) or user account with the email address entered in the email field of your Active Directory were present in your tenant’s Azure Active Directory environment, then these people could not be invited as guests in Teams. A priori I would say that this is confirmed. The MAIL user functionality in Office 365 can no longer be used if you want these people to have the opportunity to be invited into team. Because if the user can be resolved then the user will be considered as internal. If you are in hybrid mode here is the action plan I propose

The situation

  • All User accounts with mail extension (Mail User) are synchronized as such in 0365
    • This synchronization makes them appear in the address book of Exchange Online and Exchange On Prem. Teams cannot see them as an external person because they are considered internal.
  • All user accounts with the email address (in the email field) entered are synchronized as such in 0365
    • This synchronization does not show them in Exchange Online or Exchange on Premise. Teams cannot see them as an external person because they are considered internal.

Recommended solution for users with Mail User Extension

– Inventories of their membership in Exchange distribution lists

– Convert all users with Mail Extension as a Single Active Directory user

– Creation of an email contact with their email address in the 0365 or Onprem environment with synchronization to Azure AD

– Repositioning in distribution lists

Recommended solution for users whose email address is entered in the Active Directory email field

– Stop the synchronization of this type of accounts in the 0365 environments

 

Posted in Non classé | Leave a Comment »