Calendar Free/Busy Sharing in Exchange...

Exchange Online Calendar Free/Busy Sharing Feature Guide - 12.1 Release

Office 365 Dedicated & ITAR-Support Plans

Revised: November 15, 2012

© 2012 Microsoft Corporation. All rights reserved.

Calendar Free/Busy Sharing in Exchange Online IT Professional & Customer Service Desk Feature Guide

Calendar Free/Busy Sharing - 12.3 Release © 2012 Microsoft Corporation. All rights reserved.

2

The information contained in this document represents the latest available subject matter available to Microsoft

Corporation as of the date of publication. Since Microsoft must respond to changing market conditions, this document

should not be interpreted as a commitment of any type on the part of Microsoft. Further, Microsoft cannot guarantee

the accuracy of any information presented after the date of publication.

The content of this document is proprietary and confidential. The material is intended only for customers of the

dedicated and ITAR-support plans of Office 365 for enterprises. This content is provided to you under a Non-Disclosure

Agreement and cannot be distributed without the express written permission of Microsoft Corporation. Complying with

all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this

document may be reproduced, stored in, or introduced into, a retrieval system or transmitted in any form or by any

means (electronic, mechanical, photocopying, recording, or otherwise) or for any purpose without the express written

permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering

subject matter in this document. Except as expressly provided in any written license agreement from Microsoft; the

furnishing of this document does not give you any license to these patents, trademarks, copyrights, or any other

intellectual property. Reference http://www.microsoft.com/permission for additional information.

Descriptions in this document of the products of other companies, if any, are provided only as a convenience. Such

references should not be considered an endorsement of a product by Microsoft nor as an indication of support

provided by Microsoft for a third party product. Microsoft cannot guarantee the accuracy of the third party references

since product offerings of these companies may change over time. In addition, the descriptions are intended to be brief

highlights to aid understanding rather than as thorough subject matter coverage. For authoritative descriptions of

these third party products, please consult their respective manufacturer.

MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft and Windows are either registered trademarks of Microsoft Corporation in the United States and/or other

countries. The names of actual companies and products mentioned herein may be the trademarks of their respective

owners.

No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical,

without the expressed written permission of the Microsoft Corporation.

© 2012 Microsoft Corporation. All rights reserved.

http://www.microsoft.com/permission


3

About this guide 4

In scope topics 4

Out of scope topics 4

Exchange Server, Lotus Domino, & Outlook Product Fundamentals 4

Claims Based Authentication Fundamentals 4

Unsupported Functionality 4

What is Calendar Free/Busy Sharing? 5

Service Account Access Method 5

Federation Trust Access Method 6

Establishing a calendar free/busy sharing environment 9

Service Account Method Configuration 9

Federation Trust Access Method Configuration 9

Implementation Overview & Responsibilities 9

Create a Federation Trust 10

Create a TXT record for Federation 11

Manage Federation Configuration 12

Create an Organization Relationship 12

Confirming Established Federation 14

Administration of a calendar free/busy sharing environment 15

Managing Federation Relationships 15

Adding a Federated Domain 15

Organization Relationship Access Level Adjustments 15

Termination of a Federated Relationship 16

Self-Signed Certificate Renewal 16

Supporting the calendar free/busy sharing environment 17

Technical Support Roles and Responsibilities 17

Troubleshooting Resources – Federation Trust 17

Appendix A: Calendar sharing policy considerations 20

Calendar Sharing Policy Settings – Federated Trust Domain Level 20

User Level Calendar Sharing Settings – All Environments 21

Appendix B: Frequently Asked Questions (FAQs) 22


4

About this guide

In scope topics

The Microsoft Exchange Online calendar free/busy sharing options specifically for the dedicated plans of Office

365 for enterprises are described within this guide. The information provided represents features and functionality

as of the October 2012 (12.3) release. The following calendar free/busy sharing topics are addressed:

An overview of Exchange Online implementation options

How to establish an environment

Administration of the environment

Supporting the environment

Additional resources

Out of scope topics

Exchange Server, Lotus Domino, & Outlook Product Fundamentals

The functional aspects of Exchange Server and Lotus Domino (a system supported only as a specific configuration)

are not described in detail within this guide. An overview of specific Exchange functionality is presented. Detailed

information pertaining to the interworking of Exchange and Domino servers is not provided nor are specifics

describing the use of any Microsoft Outlook product to manage or retrieve calendar information.

Claims Based Authentication Fundamentals

Detailed information pertaining to claims based authentication technologies are not included within this document.

Unsupported Functionality

Any calendar free/busy sharing features or integration with external systems listed as not supported in the

Microsoft Exchange Online for Enterprises Dedicated Plans Service Description are not described within this guide.

Note: Not all generally available documentation produced by Microsoft to describe calendar free/busy

sharing for Exchange Server 2010 is applicable to the dedicated plan offerings of Office 365 for

enterprises. Documentation simply labeled Office 365 for enterprises may only pertain to the multi-tenant

version of Office 365. Content accessible via links provided within this guide and via links shown within

the Exchange Online page of the Release Documentation and Training Material area of the Office 365-

D/ITAR Customer Extranet site are reliable sources.

https://sharepoint.partners.extranet.microsoft.com/sites/MMS%20Knowledge%20Base/Release%20Docs/Exchange/Exchange%20Rel%20Docs.htm


5

What is Calendar Free/Busy Sharing? Within an Exchange Server or Exchange Online environment, messaging information including user calendar content is

primarily accessed using a Microsoft Outlook client or Microsoft Outlook Web App. Since the transition of mailboxes

from an on-premises to online environment may occur in phases over an extended period of time (a period referred to

as coexistence), methods are needed to allow calendar free/busy information for all mailbox types to be shared

between the environments. In addition, a customer optionally may need to a long term method to share calendar data

between Exchange Online and other on-premises or online environments. Within the dedicated plans of Exchange

Online, two methods are available to support the on-demand, bi-directional, transfer of calendar free/busy information

between Exchange Online and on-premises or other online environments that utilize Exchange Server 2010.

Service Account Access Method

During the coexistence phase of the transition of an on-premises Exchange environment to Exchange Online,

calendar free/busy data can be shared between the two environments using the Service Account access method.

Each environment is able to retrieve calendar information of the other environment by using Service Account

credentials to access the Client Access server (CAS) array where the information is held.

For an on-premises user to retrieve free/busy calendar data of an Exchange Online user, the target object must be

represented within the on-premises forest as either a mail-enabled user (the object state following migration of a

user mailbox to Exchange Online) or as a mail contact object. Users within Exchange Online with a desire to access

calendar free/busy information for an on-premises user must be able to recognize each mailbox-enabled user of the

on-premises environment by utilizing the object representation of the user held within the Office 365 environment.

The Microsoft Managed Solutions Service Provisioning Provider (MMSSPP) tool will forward all attributes of in-scope

on-premises objects to the Office 365 Active Directory. When an Exchange Online user initiates a calendar free/busy

data query for an on-premises user, the SMTP address for the on-premises user (e.g., [email protected]) is

determined by examining the targetaddress value of the user object held in Office 365.

As illustrated in the diagram below, when a user within the Exchange Online environment requires calendar

free/busy information for the on-premises user, the Exchange Online CAS will access the on-premises Exchange

Server using Service Account credentials to retrieve the calendar data. The Service Account access method also is

used to support a query initiated by an on-premises user to access calendar information for an Exchange Online

mailbox.


6

Key characteristics of the Service Account access method are the following:

1. The ability to view calendar free/busy data of a mailbox requires representation of the object in both the

customer on-premises environment and Office 365.

2. The on-premises Exchange Server environment must be Exchange Server 2007 or a later release.

3. For connectivity between an on-premises IBM Lotus Domino environment and Exchange Online, on-

premises enhancements must be applied per instructions provided by Microsoft.

4. Support is not provided for calendar free/busy data held on an Exchange Server 2003 system.

5. Mail clients must be Outlook 2007, Outlook Web App (premium or light versions), or a later release of an

Outlook product.

Federation Trust Access Method

The Federation Trust method to access calendar free/busy information is useful when interaction is required

between an Exchange Online dedicated plan environment and (a) several on-premises customer forests, (b) ancillary

forests associated with a customer organization, and/or (c) forests within the multi-tenant version of Exchange

Online. A federated identity relationship is a standards-based arrangement between organizations which allows

identity claims from one organization to be passed to, and recognized by, services provided by another

organization. The key components of the federated solution are the use of the Microsoft Federation Gateway and

the Security Assertion Markup Language (SAML) protocol as illustrated in the following diagram:


7

The Microsoft Federated Gateway is a free use cloud-based service offered by Microsoft that is accessed via the

Internet. For an Exchange Online dedicated plan customer, the Microsoft Federated Gateway acts as the trust broker

between Exchange Online and other federated Exchange Server 2010 environments to provide a single sign-on (SSO)

user experience which allows calendar data to be retrieved on-demand from a remote system. The Exchange Online

environment and all of the other Exchange Server 2010 environments to be federated with Exchange Online must

establish a one-time federation trust with the Microsoft Federated Gateway. The process to establish a federated trust

involves each environment providing to the Microsoft Federated Gateway a copy of their public key and a self-signed

certificate generated using their private key.


8

When the federated trust has been established between an Exchange environment and the Microsoft Federated

Gateway, a user authenticated by their local Active Directory can use Outlook or Outlook Web App to interact with the

Exchange Server in their environment to request calendar data from the remote system. The local Exchange Client

Access server (CAS) will first confirm an organization relationship with the remote domain and then request a SAML

delegation token from the Microsoft Federated Gateway. Issuance of the token is a confirmation of the local user’s

identity. The token returned contains the primary SMTP address of the requestor encrypted with the public key of the

target org. The local CAS will submit the token to the remote CAS along with the request for calendar data. The remote

CAS will use its private key to decrypt the token, verify an organization-organization relationship, and then provide the

requested data.

Key characteristics of the Federation Trust access method are the following:

1. Unlike the Service Account access method, the Active Directory user object of the remote system that is

being queried for calendar free/busy data in not required to exist in the environment where the request was

initiated; local representation of the object will allow the target mailbox to be retrieved from the Global

Address List.

2. For the Exchange Online environment, federation can only occur between the Microsoft Federation Gateway

and Exchange Server 2010 systems. If a site to be federated contains Exchange Server 2007, an Exchange

Server 2010 Client Access server must be used within the site to act as a proxy server.

3. For Exchange Online dedicated plans, support for the Federation Trust option is not provided for user

schedule availability data held on an Exchange Server 2003 system.

4. Support is not provided for an IBM Lotus Domino environment or other mail processing systems.

5. Mail clients must be Outlook 2007, Outlook Web App (premium or light versions), or a later release of an

Outlook product.

6. All servers involved in the exchange of calendar free/busy data must have Internet access to reach the

Microsoft Federation Gateway.

7. The Microsoft Federation Gateway only keeps track of the organization IDs and domains for which those

organizations have proven ownership; it does not keep track of users or the free/busy requests made by

these users.


9

Establishing a calendar free/busy sharing environment

Service Account Method Configuration

Legacy Exchange Online customers were initially configured to use the Service Account method to share calendar

free/busy data. New customers subscribing to the Exchange Online service will utilize the Federation Trust access

method.

Federation Trust Access Method Configuration

To utilize the federated calendar free/busy sharing option, the initial step for a customer is to contact a Microsoft

Service Delivery Manager to submit a Change Request (CR) to request the feature. The CR process includes a

customer review of prerequisites and also involves the initiation of the discovery process to support the

implementation. The CR process also is used to alter an aspect of a federated relationship (federated domains or

organization relationships) between Exchange Online and other qualified on-premises or online environments

utilized by the customer.

Implementation Overview & Responsibilities

The Microsoft TechNet Library contains several articles describing the topic of federated trusts involving Exchange

Server 2010. The following is an overview of the steps required to establish a federated trust involving Exchange

Online, the Microsoft Federation Gateway, and a customer premises or other external Exchange Server

environment.:

1. Create a Federation Trust

Create a unique subject key identifier for the self-signed certificate

Create a self-signed certificate for the federation trust with the Microsoft Federated Gateway

Retrieve the self-signed certificate and create the federation trust

2. Create a TXT Record for Federation

Establish domain ownership for federation

3. Manage Federation Configuration

Register account namespace with the Microsoft Federated Gateway

Add or remove federated domain

4. Create an Organization Relationship

Set free/busy access levels

Add domain name to the organization relationship


10

Following approval of a Change Request received from the customer, Microsoft will establish a federation trust

between the Exchange Online dedicated plan instance of the customer and the Microsoft Federation Gateway. The

customer will be responsible for implementing procedures to establish all other required federated relationships

for (a) all on-premises customer forests, (b) ancillary forests associated with a customer organization, and/or (c)

forests within the multi-tenant version of Exchange Online.

The information below addresses all steps required to establish a federated trust involving Exchange Online, the

Microsoft Federation Gateway, and a customer premises or other Exchange Server environment. Customers can use

the information to establish the initial federation trust between Exchange Online and their on-premises

environment. The information also can be provided to other entities affiliated with the operating environment of

the customer that also require a federation trust to be established with the Exchange Online instance of the

customer.

Create a Federation Trust

To create a federation trust for an Exchange Server environment located outside of an Exchange Online dedicated

plan environment, the steps described below must be executed from within the Exchange Management Shell of the

environment to be federated. The commands can be used as presented (parameter values within double quotes

can be altered). The Exchange 2010 Client Access server on which these commands are run must have Internet

access.

a) Create a unique subject key identifier to be used with the self-signed certificate.

$ski = [System.Guid]::NewGuid().ToString("N")

b) Create a self-signed certificate for the federation trust with the Microsoft Federated Gateway.

New-ExchangeCertificate -FriendlyName "Exchange Federated Delegation" -DomainName $env:USERDNSDOMAIN -Services Federation -KeySize 2048 -PrivateKeyExportable $true -SubjectKeyIdentifier $ski

c) The cmdlet below will retrieve the self-signed certificate and create the federation trust with the Microsoft

Federated Gateway and automatically deploy the self-signed certificate to other Exchange servers within the

organization (i.e., all CAS and HUB).

Get-ExchangeCertificate | ?{$_.friendlyname -eq "Exchange Federated Delegation"} | New-FederationTrust -Name "Microsoft Federation Gateway"


11

Create a TXT record for Federation

To service calendar free/busy requests for a specific domain name, the organization servicing those requests must

be able to prove ownership of the particular domain name. A DNS record of type TXT must be created to hold the

ownership information. The following Windows PowerShell command will create the encryption string.

Get-FederatedDomainProof -DomainName ‘mgd.customer.com’

Once the encryption string has been generated, the DNS TXT record can be created. Various methods can be used

for creating the TXT record. Shown below is an example using the DNSCmd utility. The example below creates a

TXT record in the forward lookup zone ‘mgd.customer.com’ with the federated domain proof string (shown in

double quotes) on DNS server NS1.

DNSCmd NS1 /RecordAdd ‘mgd.customer.com’ "@" TXT

"7Zyr2i/fE/M/T3AwCpitDbF30Fk/TdzXME6f7d1lDaKGthPdoS+UF94t43D2nU5hLNnIAP+5A3jJR2ik9HDPgg=="

Note: Due to characteristics of the DNS environment, special consideration must be applied if the

domain used to service free/busy requests is a sub-domain of a domain owned by a different

organization. In the example above, domain ownership is being established for ‘mgd.customer.com’

which is a sub-domain of ‘customer.com’. If an external organization establishes ownership for

‘customer.com’, that organization will effectively own all sub-domains associated with ‘customer.com’

which means only the owner of the parent domain ‘customer.com’ will be able to establish any sub-

domains which use the root domain. To avoid this issue, an organization would need to establish the

TXT record for ‘mgd.customer.com’ before the external organization establishes a TXT record for

‘customer.com’.


12

Manage Federation Configuration

Register the account namespace with the Microsoft Federated Gateway

A federated organization identifier (OrgID) is created as an account namespace for an Exchange organization

with the Microsoft Federated Gateway. The identifier enables federation for the purpose of accessing free/busy

information across Exchange organizations. A unique sub-domain for an organization will be automatically

created for the identifier. This sub-domain uses a combination of the Microsoft Federated Gateway generated

string “FYDIBOHF25SPDLT” and one of the federated domains for the organization. If the primary federated

domain of an organization is “mgd.customer.com”, for example, the “FYDIBOHF25SPDLT.mgd.customer.com”

account namespace will be automatically created as the OrgID for the federation trust. The purpose of this

subdomain is to serve as the federated namespace for the Microsoft Federated Gateway and to maintain unique

identifiers for recipients that request SAML delegation tokens.

Set-FederatedOrganizationIdentifier -DelegationFederationTrust "Microsoft

Federation Gateway" -AccountNamespace "mgd.customer.com" -Enabled $true

Subsequent to running the Set-FederatedOrganizationIdentifier command, the Get-FederationTrust

command should be run to verify that ‘ApplicationIdentifier’ and ‘ApplicationUri’ values have been

generated.

Get-FederationTrust | Format-List

Add a federated domain

Initially, a single namespace is specified for the configuration representing the relationship between Exchange

Online and the customer on-premises environment. If, at a later point, additional domain names need to be

added or removed, the Add-FederatedDomain cmdlets can be used.

Add-FederatedDomain -DomainName Contoso.co.uk

Create an Organization Relationship

For two organizations to share calendar free/busy information, each must create an organization relationship for

the other. In the example below, the organization relationship has been named ‘O365D’ and is enabled for

‘mgd.customer.com’. The values used represent the external organization from which free/busy information will be

retrieved. Included in this command is the level of free/busy access available to the organization requesting the

information. The following options are available:

Note: The value in double quotes for the DelegationFederationTrust parameter must match

the Name value used for the New-FederationTrust cmdlet used in the Create a Federation Trust

description within this document.


13

‘None’ - No free/busy access

‘AvailabilityOnly’ - Free/busy access with time only

‘LimitedDetails’ - Free/busy access with time, subject, and location

In the example below, ‘LimitedDetails’ are being made available. The requesting organization (external)

receives free/busy time, subject, and location information from the target organization.

New-OrganizationRelationship -Name "O365D" –DomainNames "customer.com" -

FreeBusyAccessEnabled $true -FreeBusyAccessLevel LimitedDetails

To add additional external domains for the purpose of requesting and sharing free/busy information, the Set-

OrganizationRelationship cmdlet needs to be used. The following parameters apply:

Set-OrganizationRelationship

Parameter

Purpose

TargetApplicationUri Represents the ‘ApplicationUri’ of the target

organization; obtained by running Get-

FederationTrust in the target organization.

TargetAutodiscoverEpr Represents the full path to the Autodiscover endpoint.

Note that this endpoint must be resolvable via DNS

and the FQDN must exist in the SAN field on the

certificate of the target.

DomainNames The external domains for which free/busy information

will be requested.

If, for example, an external organization will interact with the organization ‘contoso.com” and request free/busy

information for the domain names ‘contoso.com’, ’europe.contoso.com’, ’sales.contoso.com’,

’contosoconsulting.com’, the Autodiscover endpoint for ‘contoso.com’ must be identified. In the cmdlet example

below, ‘autodiscover.contoso.com’ is the starting path to the Autodiscover endpoint.

Set-OrganizationRelationship -Name Contoso

-TargetApplicationUri contoso.com -TargetAutodiscoverEpr

https://autodiscover.contoso.com/autodiscover/autodiscover.svc/WSSecurity

-DomainNames contoso.com,europe.contoso.com,sales.contoso.com,contoso.consulting.com

The execution of the Set-OrganizationRelationship cmdlet enable users within the local organization to request

calendar free/busy information for any user with an SMTP address with suffix of contoso.com, europe.contoso.com,

sales.contoso.com or contoso.consulting.com. The users of the organization federate with the four contoso

domains will now have access to free\busy information from the local organization based upon the

FreeBusyAccessLevel value that was set using the New-OrganizationRelationship cmdlet (see above

example).


14

Confirming Established Federation

A comprehensive test to confirm the calendar free/busy sharing arrangement is working properly between Exchange

Online and a federated Exchange Server 2010 environment is to initiate an attempt from each environment to view

calendar data of a user in the other Exchange environment. The test will confirm that federation is established and

that the Autodiscover and Availability services of Exchange are functioning properly. Use the calendar function of

Outlook 2010, Outlook 2007, Outlook Web App, or a later version of Outlook to perform the test. Add the account

name and domain name of a user in the federated environment (e.g., [email protected]) to attempt to view

free/busy information.


15

Administration of a calendar free/busy sharing environment For the Federation Trust calendar free/busy sharing method, adding to or altering an aspect of a federated relationship

(federated domains or organization relationships) may be required. Calendar sharing policies also should be considered

for either the Service Account or Federation Trust access methods.

The balance of this section will describe administrative functions for the Federation Trust method. Calendar sharing

policies are outside of the administrative scope for a base free/busy sharing environment. Appendix A describes

sharing policy topics for consideration.

Managing Federation Relationships

Adding a Federated Domain

After a federated relationship has been established for a specific domain, the need may arise to recognize

secondary domains. The following is an example involving the use of the Add-FederatedDomain cmdlet:

Add-FederatedDomain -DomainName Contoso.co.uk

See the Microsoft TechNet for more information regarding the use of the Add-FederatedDomain cmdlet.

Organization Relationship Access Level Adjustments

When the Federation Trust access method is initially established, one of the following organization relationship

settings representing the access rights for calendar free/busy data is selected within each Exchange Server

environment as described above in the Create an Organization Relationship section.

‘None’ - No free/busy access

‘AvailabilityOnly’ - Free/busy access with time only

‘LimitedDetails’ - Free/busy access with time, subject, and location

During the duration of the organization relationship between an Exchange Online dedicated plan and each

federated entity, customers can request an alteration of the access rights granted to the Exchange Online data by

placing an Office 365 Change Request with Microsoft. For the customer on-premises environment(s) or the

relationships with other external Exchange environments, the customer must address changes for these

environments following established procedures for these environments. The Windows PowerShell cmdlet

Set-OrganizationRelationship is used to alter the relationship. See Microsoft TechNet article Configure

Organization Relationship Properties for more information.

http://technet.microsoft.com/en-us/library/dd351208.aspx




16

Termination of a Federated Relationship

If a federated relationship between Exchange Online and an external Exchange Server environment must be

terminated at the domain or organization level, a customer can request this modification by placing an Office 365

Change Request with Microsoft. For other qualified on-premises or online environments utilized by the customer,

the customer must address the steps required to terminate the relationship by following established procedures for

these environments. The Windows PowerShell cmdlets Remove-FederatedDomain and Remove-

OrganizationRelationship are examples of cmdlets used to cease a specific federated relationship level. For

additional information, see the Microsoft TechNet article for each cmdlet.

Self-Signed Certificate Renewal

The certificate used to create the federation trust is designated as the current certificate. The certificate is valid for

(3) three years. Microsoft will renew the federation trust certificate for the Exchange Online environment as

required. For the customer premises and all other external Exchange environments with a federated arrangement

involving Exchange Online, the customer must establish organizational procedures to address certificate renewal.

The underlying steps to create a replacement certificate involve the generation of a new certificate and designating

it as the replacement.

To confirm a certificate is valid, the Test-FederationTrust cmdlet can be used as described in the Troubleshooting

Resources – Federation Trust section. If the results of the test indicate that the certificate has expired, the steps

described in the Create a Federation Trust section must be re-executed. The new certificate is published to the

Microsoft Federation Gateway and all new tokens exchanged with the Microsoft Federation Gateway are encrypted

using the new certificate.


17

Supporting the calendar free/busy sharing environment Prior to placing a request for support with Microsoft Online Services Support (MOSSUP), customers are expected to

first perform specific checks and diagnostics to either identify issues that may be within their environment or to gather

information which may be required to complete an escalation template. This section describes support roles and

responsibilities and also includes a description of troubleshooting resources.

Technical Support Roles and Responsibilities

The following represents an overview of roles and responsibilities involving the customer and MOSSUP:

Support Area Customer Microsoft

Confirm all IIS protocols, the Autodiscover service, and Exchange Web Services

(EWS) are functional within the customer environment and any ancillary

federated environments that report issues.

Confirm connectivity exists between the Microsoft Federation Gateway and

either the on-premises environment or ancillary federated environment that

report connectivity issues by using tools provided by Microsoft.

Confirm connectivity exists between Exchange Online and the Microsoft

Federation Gateway.

Confirm ability of Exchange Online to retrieve calendar data from a federated

Exchange Server following customer confirmation that a federated server is

functioning properly.

Troubleshooting Resources – Federation Trust

To confirm connectivity exists between the Microsoft Federation Gateway and the on-premises environment of the

customer or other external federated environments reporting connectivity issues, Windows PowerShell cmdlets

available can be used within these environments. Applicable cmdlets are the following:

Windows PowerShell cmdlet

(includes TechNet link)

Purpose

Get-FederationTrust Used to verify federation trust. Will return an

ApplicationIdentifier and ApplicationURI

value if the trust is in place and healthy.

Test-FederationTrust Verifies the items listed below. Most importantly it

verifies that the machine that the command was run

from can access the Microsoft Federated Gateway and

also request and download a delegation token.




18

Use of Get-FederationTrust will return the values mentioned in the table above. The Test-FederationTrust cmdlet

will return a collection of information as shown in the following sample output:

[PS] C:\>Test-FederationTrust

RunspaceId : 3de7795b-d572-42c3-8908-bf7677d9fecd

Id : FederationTrustConfiguration

Type : Success

Message : FederationTrust object in ActiveDirectory is valid.


Id : FederationMetadata

Type : Success

Message : The federation trust contains the same certificates published by the security token service in its

federation metadata.


Id : StsCertificate

Type : Success

Message : Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.


Id : StsPreviousCertificate

Type : Success

Message : Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.


Id : OrganizationCertificate

Type : Success

Message : Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object.


Id : TokenRequest

Type : Success

Message : Request for delegation token succeeded.


Id : TokenValidation

Type : Success

Message : Requested delegation token is valid.


19

Also available for customer use are support articles provided by Microsoft which describe potential issues related to

calendar free/busy sharing and possible issue resolution steps. To retrieve relevant support articles, use one of the

methods:

1. Access support.microsoft.com and enter the following in the search window:

exchange calendar sharing & "online dedicated"

2. Click on the following link (which represents the search query of option #1):

http://support.microsoft.com/search/default.aspx?query=exchange+archive+mailbox+%26+%22online+de

dicated%22&catalog=LCID%3D1033&mode=r

http://support.microsoft.com/?ln=en-us

http://support.microsoft.com/search/default.aspx?query=exchange+archive+mailbox+%26+%22online+dedicated%22&catalog=LCID%3D1033&mode=r

http://support.microsoft.com/search/default.aspx?query=exchange+archive+mailbox+%26+%22online+dedicated%22&catalog=LCID%3D1033&mode=r


20

Appendix A: Calendar sharing policy considerations Following the creation of a federated trust and organization relationship, setting calendar sharing policies at the

domain level should be addressed. For either the Service Account or Federated Trust calendar free/busy sharing

methods, user level calendar sharing permissions should be considered. Described below is information to consider for

both areas.

Calendar Sharing Policy Settings – Federated Trust Domain Level

When a federated organization relationship has been established between two Exchange Server 2010 environments,

a remaining step is to set calendar sharing policies at the domain level. Sharing policies are used to control how

users in an organization share calendar and contact information with external users. As described in the Microsoft

TechNet articles for the cmdlets New-SharingPolicy and Set-Sharing Policy, the following policies are available:

Sharing Policy Setting

Effect

CalendarSharingFreeBusySimple Share free/busy hours only

CalendarSharingFreeBusyDetail Share free/busy hours, subject, and location

CalendarSharingFreeBusyReviewer Share free/busy hours, subject, location, and

the body of the message or calendar item

ContactsSharing Share contacts only

The lead TechNet article for Managing Federated Delegation includes subtopics for creating, configuring, enabling,

disabling, and applying sharing policies.





21

User Level Calendar Sharing Settings – All Environments

For a user, the main task is to set free/busy sharing permissions for

their specific calendar. Using Outlook 2010 as an example, a user

can view their Calendar and right-click on the My Calendars entry

to expose the Properties… option. The Permissions tab can be

selected to expose optional free/busy settings.


22

Appendix B: Frequently Asked Questions (FAQs)

Will the Federation Trust calendar free/busy sharing feature work between (a) the Office 365 multi-

tenant and dedicated plan environments and (b) between two Office 365 dedicated plan environments?

Yes, sharing via either direction for both configurations is supported.

Will the Federation Trust calendar free/busy sharing feature replace IORepl or CalCon for Lotus Notes

during deployment coexistence?

The Inter-Organizational Replication Tool (IORepl) provides the ability to periodically place calendar free/busy

information in a public folder which is accessible to the other system of a coexistence pair. IORepl is no longer

used with Exchange Online. The Calendar Connector (CalCon) tool, used to support calendar sharing between

an Exchange Server and a Lotus Domino server, also is no longer supported. The Service Account and

Federation Trust methods are the only available options for the transfer of calendar data between Exchange

Server environments associated with Exchange Online. For the transfer of calendar data between Exchange

Online and an on-premises Lotus Domino mail server, the Binary Tree product is used during the coexistence

period with the Service Account access method only.

What is the time delay to transfer calendar free/busy information between environments?

For the Service Account or Federation Trust methods, the transfer or calendar free/busy data between the

systems is on demand. The process involves only the immediate execution of authentication protocols to allow

one system to access the data of the other system.

What are the differences between Federated Calendar Sharing and Internet Calendar Sharing?

The Exchange Team Blog article Exchange 2010 SP1 and Exchange Online (Office 365) Calendaring FAQ held in

Microsoft TechNet explains the differences between Federated Calendar Sharing and Internet Calendar Sharing.

http://blogs.technet.com/b/exchange/archive/2011/02/16/3412010.aspx

Calendar Free/Busy Sharing in Exchange...

Documents

Transcript of Calendar Free/Busy Sharing in Exchange...