Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
External calendar sharing lets users share calendar information between separate Exchange organizations. The organization that owns the calendar controls the permitted access and level of detail. The required configuration depends on where the mailboxes are hosted and whether Microsoft 365 Cross-Tenant Access Policy (XTAP) is available.
This model is different from anonymous calendar publishing. For recipients who don't use an applicable cross-tenant or federated sharing configuration, see Publish and subscribe to calendars.
Required configuration
Choose the configuration for your scenario:
- Between Microsoft 365 tenants: Use Microsoft 365 Cross-Tenant Access Policy when it's available for your tenants. XTAP replaces organization relationships and sharing policies for free/busy, shared-calendar, and MailTips access between organizations hosted in Microsoft 365.
- With on-premises Exchange organizations, including hybrid scenarios: Keep the required federation, organization relationships, and sharing policies. XTAP doesn't replace the configuration needed for access to on-premises mailboxes.
Important
XTAP is rolling out and might not yet be available in your tenant. Check the Microsoft 365 Message center and follow Migrate to Microsoft 365 Cross-Tenant Access Policy to inventory, configure, test, and migrate your existing settings. Keep sharing policies that are still needed for on-premises or hybrid organizations.
XTAP controls inbound access. For bidirectional sharing, both organizations must configure complementary policies. Follow the migration guide's testing and cleanup sequence: organization relationships take precedence for free/busy, while an applicable XTAP calendar-sharing capability takes precedence over sharing policies. An Anonymous sharing-policy entry with a higher access level can still apply, so follow the guide's instructions to configure the Anonymous capability before testing.
The federation-based configuration described in the following sections depends on these components:
- Federation trust: Establishes trust with the Microsoft identity service so Exchange organizations can exchange protected sharing information.
- Organization relationship: Identifies the external domains and controls organization-level calendar availability sharing.
- Sharing policy: Controls which external domains users can share with and the maximum calendar detail they can expose.
Tenant administrators manage these settings. Users can't override the limits established by the applicable configuration. If you're configuring or troubleshooting XTAP, use the migration guide instead of applying the federation-based steps below.
Review federation information
Use Exchange PowerShell to review the local federation configuration and retrieve federation information for the external domain:
Get-FederatedOrganizationIdentifier
Get-FederationInformation -DomainName fourthcoffee.com
Get-FederationTrust
For command details, see Get-FederatedOrganizationIdentifier, Get-FederationInformation, and Get-FederationTrust.
For Microsoft 365 organizations, the federation information for the external domain should identify Microsoft Online as the token issuer and provide the expected target application URI.
Hybrid organizations can require separate relationships for cloud and on-premises mailboxes. Verify the location of the mailboxes in both organizations before changing the configuration.
Configure an organization relationship
An organization relationship can be created in the Exchange admin center or with Exchange Online PowerShell. It should include the external organization's domains and the calendar access settings that your organization intends to expose.
Review the documented procedure in Create an organization relationship in Exchange Online.
To inspect an existing relationship, use Get-OrganizationRelationship:
Get-OrganizationRelationship |
Format-List Name,DomainNames,Enabled,FreeBusyAccessEnabled,FreeBusyAccessLevel,TargetApplicationUri
Confirm that:
- The relationship is enabled.
DomainNamesincludes the recipient's domain.- Calendar availability access is enabled at the intended level.
- The target application URI is appropriate for the external organization.
Configure the sharing policy
The sharing policy assigned to a mailbox determines which external domains the user can share with and the maximum detail level.
Use Get-Mailbox to identify the assigned policy and Get-SharingPolicy to review its domain entries:
Get-Mailbox user@contoso.com | Format-List SharingPolicy
Get-SharingPolicy "Default Sharing Policy" | Format-List Domains
A policy can contain entries for specific federated domains and a wildcard entry for other federated domains. The most specific applicable entry determines the permitted detail level.
For supported domain-entry values and syntax, see Set-SharingPolicy.
Do not configure consumer email domains as federated domain entries unless they are part of an Exchange organization with the required federation configuration. For recipients who don't use an applicable cross-tenant or federated sharing configuration, use anonymous publishing.
Troubleshoot external sharing
The recipient cannot view availability
First, identify the configuration that applies. For Microsoft 365 tenants using XTAP, verify the inbound policy in the organization that owns the calendar and follow the testing steps in Migrate to Microsoft 365 Cross-Tenant Access Policy. Existing organization relationships take precedence for free/busy, so follow the guide before disabling or removing them.
For federation-based sharing:
- Confirm that the sender and recipient addresses use the expected domains.
- Confirm that the organization relationship is enabled and includes the external domain.
- Confirm that calendar availability access is enabled at the required level.
- Confirm that federation information can be retrieved for the external domain.
- In hybrid deployments, confirm that the relationship targets the environment that hosts the mailbox.
A sharing invitation cannot be accepted
Sharing invitations contain protected data. Mail flow rules, disclaimers, routing services, or third-party message-processing products can invalidate an invitation if they change its content or message class.
- Send a new sharing invitation and accept it promptly.
- Review mail flow rules that add disclaimers or otherwise modify external messages.
- Review connectors and third-party mail-processing services in the sender's and recipient's mail paths.
- Confirm that the invitation arrives as a calendar-sharing message rather than a normal email message.
- After correcting the mail path, send a new invitation instead of reusing the modified invitation.
The available detail level is lower than expected
For XTAP calendar sharing, review the applicable inbound calendar-sharing capability in the organization that owns the calendar. When a capability applies, it takes precedence over the sharing policy, except that an Anonymous sharing-policy entry with a higher access level can still apply. See Migrate to Microsoft 365 Cross-Tenant Access Policy.
For federation-based sharing:
- Identify the sharing policy assigned to the sender's mailbox.
- Review the domain-specific and wildcard entries in that policy.
- Review the organization relationship's free/busy access level.
- Adjust only the setting that is intended to permit the additional information, and keep the exposure no broader than required.