Préparer les tenants Microsoft et Google pour les synchronisations gérées par l'administrateur

Exemple de scénario

La société X fonctionne dans un environnement mixte :

• Tenant Microsoft 365 : contoso.com (certains utilisateurs y résident)
• Tenant Google Workspace : example.com (le reste des utilisateurs y réside)

Problème actuel : les utilisateurs d'un tenant ne peuvent pas voir la disponibilité (free/busy) des utilisateurs de l'autre tenant. Objectif : permettre la visibilité de la disponibilité entre tenants. Par exemple, john.doe@contoso.com (M365) devrait pouvoir voir la disponibilité de sarah@example.com (Google), et inversement si souhaité.

Exemple concret : John (M365) doit voir Sarah (Google)

1. Source (Google) : le calendrier principal de Sarah à sarah@example.com.
2. Destination (M365) : le tenant contoso.com doit disposer d'un calendrier représentant Sarah — soit une boîte aux lettres utilisateur complète sarah@contoso.com (nécessite une licence M365), soit, recommandé, une boîte aux lettres de ressource nommée « Sarah » pour éviter d'attribuer une licence à un nouvel utilisateur.
3. CalendarBridge synchronise alors la disponibilité de Sarah depuis Google → vers le calendrier « Sarah » sur M365, afin que John (et les autres utilisateurs M365) puissent la consulter.
4. Si les utilisateurs de contoso.com invitent le calendrier de Sarah à des réunions, Sarah a également besoin d'une connexion de synchronisation inverse (M365 → Google) afin que les réunions acceptées sur le calendrier de ressource « Sarah » soient réécrites dans son véritable calendrier sarah@example.com.

Sens inverse : Sarah (Google) doit voir John (M365)

1. Source (M365) : le calendrier principal de John à john.doe@contoso.com.
2. Destination (Google) : le tenant example.com doit disposer d'un calendrier représentant John — soit une boîte aux lettres utilisateur complète john.doe@example.com (nécessite une licence Workspace), soit, recommandé, un calendrier de ressource nommé « John Doe » (aucune licence utilisateur nécessaire). Google attribue une adresse de ressource comme c_188bp5b5u2np4ghmh4psh6ra7lfl6@resource.calendar.google.com.
3. CalendarBridge synchronise alors la disponibilité de John depuis M365 → vers le calendrier de ressource « John Doe » sur Google.
4. Si les utilisateurs de example.com invitent le calendrier de John à des réunions, John a également besoin d'une connexion de synchronisation inverse (Google → M365).

Créer les calendriers nécessaires sur le tenant de destination

Sur le tenant de destination (où les personnes doivent consulter ou inviter l'utilisateur), créez un calendrier qui représente cette personne ou cette ressource.

1. Destination Microsoft 365 : créez une boîte aux lettres utilisateur (nécessite une licence M365) ou une boîte aux lettres de ressource (aucune licence nécessaire) pour la personne/ressource. Les boîtes aux lettres de ressource reçoivent automatiquement une adresse e-mail standard que CalendarBridge peut utiliser (par exemple, confroom1@contoso.com), aucun compte de service ou configuration de partage supplémentaire n'est donc requis.
2. Destination Google Workspace : chaque calendrier peut être une boîte aux lettres utilisateur (par exemple, john.doe@example.com) ou un calendrier de ressource. Les calendriers de ressource dans Google ne disposent pas d'une adresse e-mail utilisable (elle ressemble à c_…@resource.calendar.google.com), un compte de service doit donc être créé :
   1. Créez un compte de service dans le tenant Google Workspace (par exemple, cb_svc@example.com).
   2. Dans Google Calendar, connecté en tant que super administrateur, ouvrez les Paramètres et partage du calendrier de ressource.
   3. Partagez le calendrier avec le compte de service et accordez les autorisations Apporter des modifications et gérer le partage.
   CalendarBridge peut alors se connecter en utilisant l'adresse e-mail du compte de service pour synchroniser vers et depuis ce calendrier de ressource.