(English and French version )
Les fonctions de MTO permettent de faciliter « l’expérience utilisateur » lorsqu’une entreprise ou un groupe d’entreprises décident de renforcer la collaboration autour des outils Office 365. L’objectif du MTO est d’établir des règles de confiance et des stratégies de sécurité qui permettent de formaliser la collaboration entre 2 et jusqu’à 100 tenants.
Mais s’il est notable de constater que l’expérience utilisateur est améliorée lorsque le MTO est en place entre 2 tenants, toutes les fonctions que l’utilisateur est en droit d’attendre, ne sont pas forcément au rendez-vous.
C’est le cas notamment des salles de réunion qui pour l’instant ne sont pas prises en compte dans l’environnement MTO. Explication :
Si l’on considère, 2 tenants (Filiale et Maison mère) appartenant à une organisation multi tenants, et synchronisant leurs annuaires, les carnets d’adresses Exchange Online par définition, seront provisionnés et les utilisateurs du tenant filiale pourront effectivement visualiser dans la liste d’adresses globale les utilisateurs du tenant maison-mère. Du fait d’une synchronisation bidirectionnelle , l’inverse sera également possible.
Cependant la synchronisation ne va prendre en compte les salles de réunion qui ne seront pas visibles pour les deux parties. C’est effectivement une limite de la solution à ce jour. La conséquence pour les utilisateurs est qu’ils ne pourront pas réserver une salle de réunion appartenant à l’autre tenant.
Une solution qui contourne cette non prise en charge, mais qui pose d’autre problème, consiste à déclarer dans les deux tenants des mail contacts (contact a extension de messagerie) dans le but de créer une entrée d’annuaire représentant la salle de réunion. De ce fait, les utilisateurs des deux tenants auront la capacité de visualiser dans leurs carnets d’adresse les salles de réunions.
Mais cette solution pose plusieurs soucis.
Un mail contact n’est pas une salle, par conséquent les utilisateurs d’un tenant auront du mal à trouver cette entrée d’annuaire lors de la création de réunion. Cette entrée d’annuaire ne sera pas considérée par Exchange online comme une salle de réunion et par conséquent n’apparaitra pas par défaut dans les affichages de carnet d’adresse notamment All Rooms.
Le second problème est que la nature même de l’entrée d’annuaire de la salle dans l’autre tenant, étant un mail contact, l’utilisateur sera dans l’incapacité de visualiser le nombre de place par exemple comme le permet une entrée d’annuaire de type Rooms dans un carnet d’adresse.
Le troisième problème que cela pose concerne par exemple, la réservation d’une salle de réunion de la maison mère par l’utilisateur du tenant Filiale . En effet si l’utilisateur connais l’adresse Smtp de la salle ou utilise le mail contact prévu à cet effet alors, ce dernier peut effectivement inclure dans la réunion la salle en question. Mais la demande de réservation ne sera pas prise en compte dans le tenant de la maison mère car la réservation des salles de réunions n’est généralement pas ouverte vers l’extérieur.
Pour ouvrir vers l’extérieur une salle (même si d’un point de vue sécurité cette solution peut être discutée) nous avons modifié son Calendar Processing afin que le paramètre ProcessExternalMeetingMessages soit passée à $True.
La documentation Microsoft précise la fonction de ce paramètre pour une salle
–ProcessExternalMeetingMessages
The ProcessExternalMeetingMessages parameter specifies whether to process meeting requests that originate outside the Exchange organization. Valid values are:
- $true: Meeting requests from external senders are processed.
- $false: Meeting requests from external senders are rejected. This is the default value.
Nous avons donc passé la commande suivante :
Set-CalendarProcessing -Identity « Room 221 » -ProcessExternalMeetingMessages $true
En faisant cela, on autorise en théorie, quiconque sur internet ayant l’adresse Smtp de la salle à envoyer des demandes de réservation. Pour pouvoir éventuellement limiter cette fonctionnalité à des domaines connus, je pense qu’il faudra recourir à la création de règle de transport dont la fonction sera de supprimer toutes les demandes externes de réservation d’une salle sauf si le domaine de l’expéditeur correspond aux domaines Smtp de l’autre tenant.
En faisant un test et en utilisant un utilisateur du tenant filiale, et en ayant vérifier que la salle du tenant de la maison mère avait le paramètre -ProcessExternalMeetingMessages à la valeur $true, nous n’avons pas pu visualiser dans l’agenda de la salle la demande de réunion de l’utilisateur du tenant filiale alors qu’un destinataire du tenant maison mère de cette même réunion a bien l’invitation dans son calendrier.
Pour tenter de résoudre ce problème ou pour trouver une solution plus acceptable, nous avons donc ouvert un case auprès des équipes supports Microsoft.
********************************
MTO functions facilitate the “user experience” when a company or group of companies decide to strengthen collaboration around Office 365 tools. The aim of MTO is to establish trust rules and security strategies that formalize collaboration between 2 and up to 100 tenants.
But while it is notable that the user experience is improved when the MTO is in place between 2 tenants, not all the functions that the user is entitled to expect, are necessarily there.
This is particularly true of meeting rooms, which are currently not included in the MTO environment. Explanation:
If we consider 2 tenants (Subsidiary and Parent Company) belonging to a multi-tenant organization, and synchronizing their directories, Exchange Online address books by definition will be provisioned, and users of the Subsidiary tenant will effectively be able to view users of the Parent Company tenant in the global address list. Thanks to bidirectional synchronization, the reverse will also be possible.
However, synchronization will not take into account meeting rooms, which will not be visible to both parties. This is indeed a limitation of the solution to date. The consequence for users is that they will not be able to reserve a meeting room belonging to the other party.
A solution that gets around this lack of support, but poses other problems, is to declare mail contacts (contact with mail extension) in both tenants in order to create a directory entry representing the meeting room. As a result, users of both tenants will be able to view meeting rooms in their address books.
But this solution poses several problems.
A mail contact is not a room, so users will have difficulty finding this directory entry when creating a meeting. This directory entry will not be considered by Exchange online as a meeting room, and consequently will not appear by default in address book displays such as All Rooms.
The second problem is that the very nature of the room directory entry in the other tenant, being a contact mail, means that the user will be unable to view the number of places, for example, as is possible with a Rooms-type directory entry in an address book.
The third problem this poses concerns, for example, the reservation of a meeting room at the parent company by the user of the Subsidiary tenant. If the user knows the Smtp address of the room, or uses the contact mail provided for this purpose, then he or she can actually include the room in question in the meeting. However, the reservation request will not be taken into account by the parent company, as meeting room reservations are generally not open to the outside world.
To open up a room to the outside world (although from a security point of view this solution is debatable), we have modified its Calendar Processing so that the ProcessExternalMeetingMessages parameter is set to $True.
The ProcessExternalMeetingMessages parameter specifies whether to process meeting requests that originate outside the Exchange organization. Valid values are:
- $true: Meeting requests from external senders are processed.
- $false: Meeting requests from external senders are rejected. This is the default value.
We therefore issued the following command:
Set-CalendarProcessing -Identity « Room 221 » -ProcessExternalMeetingMessages $true
By doing this, we theoretically authorize anyone on the Internet with the room’s Smtp address to send reservation requests. To be able to limit this functionality to known domains, I think we’ll need to create a transport rule whose function will be to suppress all external booking requests for a room unless the sender’s domain matches the Smtp domains of the other tenant.
When we ran a test using a user from the subsidiary holding company, and having checked that the room from the parent company holding company had the -ProcessExternalMeetingMessages parameter set to $true, we were unable to view the meeting request from the user from the subsidiary holding company in the room’s calendar, whereas a recipient from the parent company holding company for the same meeting had the invitation in his calendar.
To try and solve this problem, or to find a more acceptable solution, we opened a case with the Microsoft support teams.
Travailler ensemble 