FindTime, your favorite scheduling add-in just got better!
We heard you and so we re-wrote the entire back-end infrastructure for FindTime, we built a new service within the Office 365 compliance boundary! More specifically, the organizer’s poll data is now stored in their mailbox and will not leave your tenant’s environment.Configuring Teams calendar access for Exchange on-premises mailboxes
Over the last several months, we have seen many customers adopting Microsoft Teams, even if their mailboxes are still hosted in an on-premises environment. One of the common issues in this scenario is not being able to see the Calendar tab in the Microsoft Teams client.Common mailbox / folder sharing scenarios Guided Walkthroughs now available
Exchange and Outlook have, for years, been great collaboration platforms, where our customers could share information easily with others. One of the things that came to light when a lot of our customers adopted Office 365, is that many often have trouble matching their business needs to actual features in the product (stuff they would see in user interfaces and need to configure). In a purely on-premises world, the internal helpdesk and training can help bridge that gap. For those of our customers that have moved to the Office 365 world (especially smaller organizations), this can be a bit of a challenge. We have worked to understand what most commonly looked for (and not found!) sharing scenarios are, and have leveraged the Guided Walkthrough (GWT) framework to help guide customers to correct features they need to get them enabled, taking into the consideration various clients and editions of service they might have. It is worth mentioning that scenarios and steps listed in these GWT s apply to both Exchange Online and on-premises Exchange Server deployments. Typically, the on-premises workflow is the same as can be found if one chooses the “Enterprise Edition” option in those GWT s. Because many of these scenarios are what end-users can accomplish, I would be interested to hear your feedback whether a purely on-premises version would be useful, seeing that on-premises organizations are likely to have resources such as internal help desks and training. Please elaborate a bit in comments if you can, in case you see the value is separate versions? Here are the new GWTs: Sharing calendar and contacts in Office 365 Setting up a mailbox that multiple users can access and use in Office 365 Sending email from another person's mailbox or from a group in Office 365 Accessing other people’s mailboxes in Office 365 Creating and managing resource mailboxes (conference rooms/equipment) in Office 365 It has become a bit of a tradition to thank people who worked on GWT s when we announce them, so not to disappoint, I’d like to thank: Nagesh Mahadev, Jon Bradley, Charlotte Raymundo, Jon Hoerlein, Kweku Ako-Adjei, Sharon Shen, Chen Jiang as well as Scott Vidican, Adam Dudsic and Victor Zhang (ECO). Hope you find this useful. You can give us feedback on Exchange GWTs by either posting a comment in this post (if it is about the 5 GWT listed above) or emailing ExchGWTfeedback AT microsoft.com if it's about any Exchange GWT s. Nino BilicRaising diagnostic logging for Message Access might cause calendar issues with Exchange 2007 SP2
There is potential for calendar related problems when new diagnostic logging for Message Access, which is available in Exchange Server 2007 Service Pack 2 (SP2) is raised from its default setting of Lowest. A Knowledge Base article and a fix are in the works at this time and will be available soon. Important - some calendar items may remain broken even after applying the update. This post addresses scenarios where those lingering symptoms remain. What the users may see Symptoms before applying the pending update: Access to recurring appointments (which have attachments for the instances) is broken - Outlook in online mode receives an "Item cannot be opened" error. Sending an embedded message in cached mode results in the attachment being stripped. Availability is not shown for some users. The following symptoms may persist, even after applying the update or manually setting the Message Access diagnostic level back to Lowest: Certain users show no availability information from Outlook or OWA scheduling assistant. Also, event id 4009 for MSExchange Availability is logged on servers with the CAS role Exception returned: Microsoft.Exchange.Data.Storage.ObjectNotFoundException: Cannot open embedded message. Delegates viewing calendars receive the error: Cannot read on instance of this recurring appointment. Close any open appointments and try again, or recreate the appointment Messages are sent to ActiveSync devices with the following text: Microsoft Exchange was unable to send the following items to your mobile device. These items have not been deleted. You should be able to access them using either Outlook or Outlook Web Access. When accessing Calendar from OWA, the day, week or month viewing will fail with the error: The item that you attempted to access no longer exists. We have determined these symptoms are primarily due to calendar items affected between the time logging was increased and when the pending update or workaround is implemented. Recurring calendar items with no end date that have had an occurrence modified seem most susceptible. A quick method to find these visually is to look for the circling arrows with a line through it. Does this apply to you? Before the release of the pending update, if any Exchange Server 2007 SP2 server with the Mailbox role has the following new event log level raised from Lowest, this applies to you. MSExchangeIS\9000 Private\Message Access How to check your Organization for the problem You can determine if your MBX servers are at risk by looking in the following places: 1) The new GUI introduced in SP2 - in the Exchange Management Console under Server Configuration, Mailbox, select the server and choose Manage Diagnostic Logging Properties... 2) In the registry for each MBX server [Lowest = 0] 3) Run the following Exchange CMDlet to find all Exchange 2007 MBX servers and this specific diagnostic logging level for Message Access: Get-MailboxServer | foreach {Get-EventLogLevel -id ($_.name + "\MSExchangeIS\9000 Private\Message Access")} How to correct the problem If any MBX server is found to have logging above the default before the pending update is applied, you should reset it to Lowest manually. Note which MBX servers are configured with the non-default level and then run this CMDlet to ensure they are all set to "Lowest" Then either remount the databases or restart the Information Store service. Get-MailboxServer | foreach {Set-EventLogLevel -id ($_.name + "\MSExchangeIS\9000 Private\Message Access") -Level "Lowest"} A sample PowerShell script is available as an attachment on this blog post to track down calendar items contributing to the symptoms that persist after applying the workaround detailed above. This script will identify the day containing problem appointments and can be run against a specific mailbox or all Exchange 2007 mailboxes. The requirements for running the script are detailed in the script comments. The sample script uses the $true argument to enumerate all Exchange 2007 mailboxes and user42@contoso.com to initialize the Autodiscover portion of the Web Services object: [PS] C:\Powershell\scripts> .\Find-BadCalendarItems.ps1 user42@contoso.com $true Checking mailbox: user01@contoso.com Checking mailbox: user02@contoso.com ... Checking mailbox: user42@contoso.com Checking mailbox: repro01@contoso.com Failed: 11/30/2009 - 12/30/2009 Error: Mailbox logon failed., inner exception: Cannot open embedded message. Day failed: 12/2/2009 Checking mailbox: repro02@contoso.com Failed : 11/30/2009 - 12/30/2009 Error: Mailbox logon failed., inner exception: Cannot open embedded message. Day failed: 12/23/2009 Checking mailbox: user43@contoso.com Checking mailbox: lastuser@contoso.com Problems found: repro01@contoso.com: 12/2/2009 repro02@contoso.com: 12/23/2009 Done! Now that 12/23/2009 has been identified as the problem date for user repro02@contoso.com, you can use Outlook to find any recurring calendar items with no end date that have had an occurrence modified on that day. Copy that occurrence [either to a temporary Calendar folder or even to a different time that day] then delete just that occurrence. Moving the copy back or manually recreating the instance will resolve the symptom for that user. - Austin McCollum, Bill Long, Jon Runyon, Kris WatersExchange 2010 SP1 and Exchange Online (Office 365) Calendaring FAQ
Exchange 2010 SP1 and Exchange Online (Office 365) incorporate federation to enable secure organization-to-organization free/busy and calendar sharing with other Exchange organizations. Also new is the ability for users to publish their calendar in iCal format to anyone, and for them to subscribe to internet calendars. With Exchange now providing options for how your users can share calendar data with others inside and outside your organization, we've received a number of common questions about the differences in setup and functionality between sharing methods. These questions and their responses below can provide clarity as you consider calendar sharing in your organization. - David Alexander Technical Product Manager What is the difference between Federated Calendar Sharing and Internet Calendar Sharing, and why do Federated Sharing instead of Internet Sharing? Exchange 2010 SP1 provides organizations with options for how their users can share calendar data with others inside and outside the organization, based on organizational requirements. Internet Calendar Sharing allows users to share (and subscribe to) calendar data in iCalendar format with any anybody, inside or outside the organization, whether those recipients are using Exchange, another platform, or simply a web browser. Internet Calendar Sharing does not require authenticated access or Federated Trust, and the only setup required is for the Exchange administrator to turn the feature on. Federated Calendar Sharing enables authenticated access to users' calendar data, and it is available only between Online and/or on-premises Exchange organizations who have established a Federation Trust with the Microsoft Federation Gateway, which acts as a broker between Federated organizations. In the case of both Federated Calendar Sharing and Internet Calendar Sharing, the on-premises or Online Exchange administrator can control with what level of granularity users are able to share calendar data (free/busy only, free/busy with titles/locations, or full calendar details). Administrators can define a Sharing Policy and apply that to the entire org, certain divisions, or even individual users. Within the scope of what the administrator has allowed, a user has the option to publish their data with even less granularity. Why do Federated Sharing vs. Internet Sharing? Not all organizations wish to enable anonymous (unauthenticated) access to calendar data at any level of granularity, in which case Federated Sharing is the way to go. Federated Sharing can also allow org-wide access to free/busy information between orgs based on org-org relationships set up by the admin, as well as the sharing of contact folders. In Internet Calendar Sharing, can a privately shared calendar really be private? What if somebody forwards the link I sent to another person who shouldn't have access to my calendar? In order for Exchange 2010 SP1/Exchange Online (Office 365) to deliver on the promise to let Exchange users share/consume calendars with anybody, even non-Exchange users, we had to relax the requirement for authenticated access and allow for the anonymous access to users' calendar data (within the scope allowed by the Exchange administrator). Exchange has a number of built-in features to address security concerns an organization might have with anonymous access. For one, Internet Publishing is OFF by default, and an admin can decide whether the whole org, certain divisions, or even individual users have Internet Calendar Sharing enabled or not, and at what level of detail. Exchange also bases the Calendar Sharing from a dedicated calendar sub-virtual directory off the OWA vdir, and this calendar vdir is set with HTTP access while OWA is set with HTTPS, so admins do not allow anonymous access to the OWA parent vdir by turning this on. When Internet Calendar Sharing is turned on, Exchange can provide a level of security for those wishing to privately share their calendar, by obfuscating the calendar sharing URL, or formatting it such that it cannot be guessed or discovered by searching on the internet. Exchange does not control how a URL owner or recipients distribute this restricted URL. However, if a restricted URL is distributed further than originally intended, or if an owner wishes to update with whom their calendar is shared, they can reset the URL at any time. The owner simply stops and then restarts publishing, which generates a new obfuscated/restricted URL, and then chooses a new set of URL recipients. The old URL no longer allows access to the owner's calendar data. If anonymous access to users' calendar data at any level of granularity does not meet an Exchange organization's security needs, Exchange 2010 SP1/Exchange Online (Office 365) has made it even easier to set up Federated Calendar Sharing between Exchange orgs wishing to share calendar data in an authenticated fashion. How do Exchange 2010 SP1/Exchange Online (Office 365) organizations set up Federated Calendar Sharing? To set up Federated Calendar Sharing between Exchange 2010 SP1/Exchange Online (Office 365) organizations, both must have Federated Trust established with the Microsoft Federation Gateway. Trust with the gateway is automatically established for Exchange Online (Office 365) organizations. On-premises organizations must manually establish Trust with the gateway, but this has become even more simplified in Exchange 2010 SP1. Information on how to create a Federation Trust can be found on this TechNet site. Once Federated Trust is established with the gateway, the Default Sharing Policy allows individual users to make calendar sharing invitations to users of other Federated orgs at only the most basic level of detail (free/busy only). Users will need Outlook 2010 or OWA to set up sharing. The Exchange admin can then modify that Sharing Policy, or create an additional Sharing Policy, to allow more detail to be shared. The admin can apply that more detail-visible policy to all users in the org, certain subsets of users, or even just specific users. The admin can also disable the Default Sharing Policy altogether so users without an explicit policy assigned cannot share their calendar at any level of detail. To configure these Sharing Policies, Online tenant admins will need to use Remote PowerShell, while there is EMC support for on-premises admins. More information about configuring Sharing Policies can be found on this TechNet article. Instructions for how enabled users can do Federated Calendar Sharing are available for those using Outlook Web App and Outlook 2010. Another option the admin has is to create an org-org relationship with another Federated org. That relationship allows the free/busy information for every user to be available to the other Federated org without the need for individual users to make a sharing invitation of any kind. The admin can also choose the level of free/busy detail shown when defining that org-org relationship. More information about configuring org-org relationships can be found on this TechNet article. A comparison between Sharing Policies and org-org relationships can be found on this TechNet article. Within the scope of admin-defined Sharing Policies, org-org relationships, or both, users can always individually choose to limit the detail of their sharing further. Some customers wonder how much information about them and their users the Microsoft Federation Gateway stores. The gateway only keeps track of the organization IDs and domains for which those orgs have proven ownership. It does not keep track of users or what free/busy requests they have made. Can an Exchange Online (Office 365) customer establish Federated Calendar Sharing with another Exchange Online customer, as well as a third customer who is running on-premises Exchange Server 2010 SP1? Yes. An Exchange Online (Office 365) customer can set up Federated Calendar Sharing with other Exchange Online organizations, in addition to Exchange 2010 SP1 on-premises orgs. More information about Federated Calendar Sharing specifically between Office 365 customers can be found at this help.outlook.com article. How does setting up Internet Calendar Publishing differ for Online vs. on-premises? For both Exchange 2010 SP1 and Exchange Online (Office 365), it is important to remember that no data can be published until the admin has set the sharing policy. Steps for enabling Internet Calendar Publishing can be found on this TechNet article. It is important to note that for Online tenant admins, configuring the Web proxy URL for the Mailbox server, and running the cmdlet which enables calendar publishing and turns on the calendar virtual directory, have both been done in the datacenter already. Instructions for how enabled users can publish their calendars to the internet are available for those using Outlook Web App. Outlook 2010 uses the Autodiscover service to light up a publishing option for its Exchange users (besides publishing to Office.com or a WebDAV server). On the Home tab, in the Share group, Outlook 2010 users can click "Publish this Calendar," which will redirect them to Outlook Web App to complete the publishing process. On-premises and tenant admins can publish a calendar for a user using PowerShell, using the cmdlet set-mailboxcalendarfolder and associated parameters. The user must have a Sharing Policy assigned that allows publishing. When Federated Sharing is set up between Exchange 2010 SP1/Exchange Online (Office 365) organizations, will that include Federated GAL? While Federated Sharing between two Exchange 2010 SP1/Exchange Online (Office 365) organizations can allow the sharing of an individual user's calendar folders (as well as contact folders), Federated GAL sharing between the two orgs is not possible whether they are Online or on-premises. For customers wishing to share GAL information between on-premises Exchange organizations, they can use a tool like Microsoft Forefront Identity Manager 2010 to enable custom syncing between orgs. For Office 365 customers, the Directory Synchronization (DirSync) tool maintains unified GAL between users on-premises and in the cloud. In Exchange Online (Office 365), is an org-org relationship required between two organizations which wish to enable Federated Calendar Sharing? An org-org relationship is not required between Exchange Online (Office 365) customers who wish to enable Federated Calendar Sharing. Trust with the Microsoft Federation Gateway is automatically established for Exchange Online (Office 365) orgs, so upon sign-up for the service, the Default Sharing Policy allows individual users of Online orgs to invite users of other Federated orgs to view/share their calendars at the most basic level of detail (free/busy only), without any administrator action. Users will need Outlook 2010 or OWA to set up sharing. Using Remote PowerShell, the tenant admin can modify that Sharing Policy, or create an additional Sharing Policy, to allow more detail to be shared. The admin can apply that more detail-visible policy to all users in the org, certain subsets of users, or even just specific users. The admin can also disable the Default Sharing Policy altogether so users without an explicit policy assigned cannot share their calendar at any level of detail. Visit TechNet for more details on disabling the Default Sharing Policy and creating a new Sharing Policy. An org-org relationship is required if the tenant admin wishes to allow free/busy information for every user in the Online org to be available to another Online org without the need for individual users to make a sharing invitation of any kind. The admin can again choose the level of free/busy detail shown when defining that org-org relationship. A comparison between Sharing Policies and org-org relationships can be found on this TechNet article. Within the scope of admin-defined Sharing Policies, org-org relationships, or both, users can always individually choose to limit the detail of their sharing further. What (if any) calendar sharing or free/busy viewing capabilities do I get with federation through ADFS in Exchange 2010 SP1, vs. setting up Federated Trust with the Microsoft Federation Gateway? Federation through ADFS does not enable any type of calendar data exchange (neither full sharing nor free/busy viewing) between organizations, whether they are Exchange 2010 SP1 or older. ADFS only enables federated identity (and thereby single sign-on) across forests. Two organizations with trusted forests, federating through ADFS, wishing to allow free/busy viewing cross-org would need to use Add-AvailabilityAddressSpace objects to define the access method and associated credentials used to exchange free/busy data across their trusted forests (see TechNet article). Establishing Federated Trust with the Microsoft Federation Gateway is required to enable full Federated Calendar Sharing functionality. Federated Calendar Sharing does not require ADFS to enable any of its functionality, nor will having ADFS impact its functionality. How can users in my Exchange organization share calendars with users in non-Exchange organizations? Internet Calendar Sharing might be an option for sharing between Exchange and non-Exchange organizations. If the non-Exchange organization has the ability to publish calendars in iCalendar format, then Exchange 2010 SP1/Exchange Online (Office 365) users can consume them (and publish their own reciprocally). This includes cloud users on Windows Live, Yahoo, and Google. Also an individual user of Outlook 2007 or 2010, whose calendar is not on an Exchange account, has the ability to publish their calendar to Office.com and can share it in that way (see more information). Exchange currently does not have a federation story with non-Exchange organizations, so Federated Calendar Sharing is not possible between Exchange and non-Exchange users. Calendar Delegates: are there other folders that could get delegated? Calendar delegates work in Exchange 2010 SP1/Exchange Online (Office 365). Cross-premises delegates (e.g. where a manager is in the datacenter and the delegate is on-premises, or vice-versa) is not supported. Calendar delegates can only be set for your default calendar folder. Within Exchange 2010 SP1/Exchange Online (Office 365) you can grant other users editor (but not delegate) permissions to secondary calendar folders. How can two different Exchange organizations (Org A and Org B) enable Full Calendar Sharing or org-org Free/Busy viewing? Please visit the Exchange Team Blog Files to review a calendar sharing matrix (attached to this post) with requirements for calendar data exchange two different organizations. For Office 365 organizations in a hybrid Exchange deployment (some users on-premises, some users in Exchange Online), what Free/Busy viewing and Calendar sharing options are available? Please visit the Exchange Team Blog Files to review a calendar sharing matrix (attached to this post) with requirements for an organization in a hybrid deployment.Calendaring is Really Hard to Code and That’s Why You Were An Hour Late to that Meeting
Writing code for calendaring features is hard. You finally figure out a good time for your team to meet and then one of the attendees happens to live in a country that decided to implement Daylight Saving Time (DST) and change the local time by an hour. Just in that country. Here's some advice on what to do and how to handle it.Cross Org Availability using Federation Trust and Organization Relationship
Note: To ensure that you see more up to date guidance related to this scenario, please see this blog post. Organizations often need to share availability (aka Free/Busy) information with other Exchange organizations. Depending on the version of Exchange Server you're on, there are different ways to do this. Let's take a look at three common scenarios and go through the exact steps required in order to achieve sharing of availability information between two on-premises Exchange organizations. Scenarios: Scenario 1: Both organizations running Exchange 2010 SP1 Scenario 2: One (or both) organizations running a mix of both Exchange 2007 and Exchange 2010 SP1 Scenario 3: One (or both) organizations running a mix of Exchange 2003, Exchange 2007 and Exchange 2010 SP1 This summary table outlines the requirements in order to facilitate Availability lookups between two organizations: Exchange Version present in Source organization Required Components Exchange 2003/2010 Exchange 2003/2007/2010 Exchange 2007/2010 Exchange 2010 Federation Trust/ Organization Relationship X X X X Availability Address Space - X X - Public Folder Database on 2010 Sp1 with Replicas of some/all Free/Busy folders* X X -- *refer to “Option A” and Option B” which are discussed later in this post Scenario 1: Both organizations are running Exchange 2010 Sp1 This is the simplest scenario. Users in both organizations are on Exchange 2010, both organizations can use Federated Delegation and do not require any additional steps. Both organizations must first set up a Federation Trust. The steps to create a Federation trust are documented in Create a Federation Trust. The Federation Trust should be in place and working for both organizations before the organization relationship is set up. Register the DNS TXT records for the federated domain namespace and all other domains you wish to add to the federation trust. The account namespace (this is the federated delegation organization identifier or OrgID) identifies your organization to the Microsoft Federation Gateway. You must use a domain other than your primary SMTP domain (used to receive inbound email) for the account namespace, as documented in Configure Federated Delegation. The current recommendation is to use exchangedelegation.domain.com as the account namespace. Ensure that the autodiscover web service is configured and working for your domain namespace. Although it's possible to manually configure the organization relationship, we recommended that you use autodiscover. Create an organization relationship with the remote organization. The steps to create an organization relationship are documented in Create an Organization Relationship. Note: Directory synchronization is not required in order to do cross-org availability in Exchange 2010 SP1, except if you have users on Outlook 2007/2003. However, if you choose to configure directory synchronization, it'll not impact the ability to perform availability lookups. Scenario 2: One or both organizations are running Exchange 2010 SP1 and Exchange 2007 Steps 1-4 in this scenario are the same as Scenario 1. However, with Exchange 2007 in the mix, directory synchronization is requiredbetween the two organizations. You must also create an availability address space for the remote organization. This allows Exchange 2007 users in both organizations to benefit from Exchange 2010's support for federation. For Exchange 2007 to query availability cross org, directory synchronization must be performed for all users for which Free/Busy needs to be shared. This can be performed either manually (create Exchange contacts or Mail-enabled users one at a time), or via an automated process (MIIS, ILM, FIM, other 3rd party dirsync tool, etc.).Dirsync is required in this case because Exchange 2007 requires (and expects) a local object when the availability request is performed. If no local Exchange object is present, the availability request will fail. Create a new availability address space for the remote organization that directs availability request from 2007 users to the 2010 Sp1 server. The syntax for creating the availability address space is included below. Add-AvailabilityAddressSpace -AccessMethod InternalProxy -ProxyUrl https://Exchange2010SP1CAS.InternalDomain.com/ews/exchange.asmx -ForestName Fabrikam.com -UseServiceAccount $True With this setting, when an Exchange 2007 user requests availability information for a user from the remote org, the request will be proxied through the Exchange 2010 Sp1 server, which then will utilize the Federation Trust and Organization Relationship to send the availability request to the remote forest availability endpoint. Figure 1: Exchange 2007 user requests availability for a user in remote organization Step 1. Exchange 2007 user requests availability from user in Org B. Exchange 2007 proxies the request to the Exchange 2010 SP1 server. Step 2 and 3. Exchange 2010 detects it is for a remote org, and detects there's an Organization Relationship. Exchange then validates the Federation Trust. Step 4. Exchange 2010 then sends a request to the Availability service endpoint for Org B. Step 5. The Availability service in Org B generates a respond and sends back to the Exchange 2010 SP1 CAS server in Org A. Step 6. The availability response is returned to Exchange 2007, which then returns the response to the client. Scenario 3: One or both organizations are running Exchange 2003, Exchange 2007 and Exchange 2010 SP1 Steps 1-4 in this scenario are the same as Scenario 1. Steps 5-6 in this scenario are the same as Scenario 2. Additionally, since you have Exchange 2003 in the topology, you must choose one of the two options described below in Option A and Option B. With either option, there are considerations that must be made. Please reference the known issues section at the end of this post to better understand these considerations. With both options, it's assumed that you have performed all previous steps outlined in Scenario 1 and Scenario 2. Option A: Ensure that there is an Exchange 2010 Sp1 Mailbox server that hosts a Public Folder database. Move ALL replicas of Free/Busy public folders to the Exchange 2010 Sp1 Public Folder server, and remove ALL replicas from either 2003 or 2007. This will allow Exchange 2010 SP1 to respond to all Public Folder free/busy requests.As the Public Folder free/busy query comes in, the Microsoft Exchange RPC Client Access Service on the Mailbox server (utilized for Public Folder connections) will intercept the public folder query, and route the request to the Availability service, which will then process the request as outlined in previous scenarios If the remote organization that you need to look up Free/Busy for contains Exchange 2003 users, you must manually populate the targetSharingEPR property on the Organization Relationship (reference Issue #4 at the end of this document). This is done via the Exchange Management Shell by running this command: Set-organizationrelationship –identity “Org Relationship name” –TargetSharingEPR https://outlook.contoso.com/ews/exchange.asmx/wssecurity Note: the actual URL that you use will differ from the example above. You can determine the URL by checking the ExternalURL property for your Web Services virtual directory. This can be obtained by running Get-WebServicesVirtualDirectory –server 2010cas.contoso.com | fl name, *url* Figure 2: Exchange 2003 user requests availability information for user in remote org (Option A) Step 1. Exchange 2003 user requests availability from user in Org B. Since the mailbox is on an Exchange 2003 server, the client will only perform a free/busy query to Public Folders. This is done by looking up the LegacyExchangeDN attribute on the mail-enabled object for the remote user. From the LegacyExchangeDN, the client determines the Administrative Group in which the object was created and then knows which Free/Busy public folder to look in. Outlook first performs a query to the default Public Folder database for its mailbox store (which will typically be the Exchange 2003 Public Folder store).For example, Joe User's LegacyExchangeDN is LegacyExchangeDN=/o=First Organization/ou=Exchange 2003 Admin Group/cn=Recipients/cn=Joe User. The first part of the LegacyExchangeDN, /o=First Organization/ou=Exchange 2003 Admin Group is used to determine which Free/Busy public folder to look in. The second part of the LegacyExchangeDN, cn=Joe User, is used to look for the existence of a public folder message within that Free/Busy folder. Step 2. The Exchange 2003 Public Folder database will issue a referral to the client to the Exchange 2010 SP1 Public Folder database, which is where the only replica of that Free/Busy public folder resides. Step 3. Outlook queries the Exchange 2010 SP1 Public Folder for Free/Busy. Microsoft Exchange RPC Client Access Service running on the Mailbox server intercepts the Free/Busy request and routes it to the Availability service. Step 4 and 5. Exchange 2010 detects it is for a remote org, and detects there is an Organization Relationship. Exchange then validates the Federation Trust. Step 6. Exchange 2010 then sends a request to the Availability service endpoint for Org B. Step 7. The Availability service in Org B generates a response and sends it back to the Exchange 2010 SP1 CAS server in Org A. Step 8. Microsoft Exchange RPC Client Access Service translates the availability response into a Public Folder free/busy response, and returns the information to the Outlook client. In addition, the availability response is placed into the Free/Busy Public Folder and cached for 15 minutes. If additional availability queries are performed for that remote user within that 15 minute period, they will be returned from the cache. Option B Ensure that there's an Exchange 2010 SP1 Mailbox server that hosts a Public Folder database. If not already present, create the Free/Busy system folder called External (FYDIBOHF25SPDLT) and ensure that the only replica of this Free/Busy Folder is on the Exchange 2010 SP1 server. Note:This External free busy folder will only be created on a new Exchange 2010 SP1 install when the option to create the public folders is selected during setup. The option is only presented if it's the first server installed in the organization. If a public folder database was not created during setup, you'll need to manually create this folder. The process to create this External folder is simple. Connect to the on-premise Exchange 2010 SP1 Public Folder server (this has to be done from the Public Folder server) Open Windows PowerShell Type " Add-PsSnapin Microsoft.Exchange.Management.Powershell.Setup" Then Type " Install-FreeBusyFolder" This will create the new Schedule Plus free busy folder called "External (FYDIBOHF25SPDLT)". Modify the LegacyExchangeDN on all mail-enabled objects that reference the remote organization and change the OU value to External (FYDIBOHF25SPDLT). As the Public Folder free/busy query comes in, the Microsoft Exchange RPC Client Access Service on the Mailbox server (utilized for Public Folder connections) will intercept the public folder query and route the request to the Availability service, which will then process the request as outlined in previous scenarios. If the remote organization that you need to look up Free/Busy for contains Exchange 2003 users, you must manually populate the TargetSharingEPR property on the Organization Relationship (reference Issue #4 at the end of this document). This command populates the TargetSharingEPRproperty: Set-OrganizationRelationship –Identity “Org Relationship name” –TargetSharingEPR https://outlook.contoso.com/ews/exchange.asmx/wssecurity Note: the actual URL that you use will differ from the example above. You can determine the URL by checking the ExternalURL property for your Web Services virtual directory. You can obtain it by running Get-WebServicesVirtualDirectory –Server 2010cas.contoso.com | fl Name, *url* Figure 3: Exchange 2003 user requests availability information for user in remote org (Option B) Step 1. Exchange 2003 user requests availability from user in Org B. Since the requesting client mailbox is on an Exchange 2003 server, the client will only perform a free/busy query to Public Folders. This is done by looking up the LegacyExchangeDNattribute on the mail-enabled object for the remote user. From the LegacyExchangeDN, the client determines which Administrative Group the object was created in, and then knows which Free/Busy public folder to look in. Outlook first performs a query to the default Public Folder database for its mailbox store (which will typically be the Exchange 2003 Public Folder store).For example: LegacyExchangeDN=/o=First Organization/ou= External (FYDIBOHF25SPDLT)/cn=Recipients/cn=Joe User. The first part of the LegacyExchangeDN, /o=First Organization/ou= External (FYDIBOHF25SPDLT)/is used to determine which Free/Busy public folder to look in. The second part of the LegacyExchangeDN, cn=Joe User, is used to look for the existence of a public folder message within that Free/Busy folder. Step 2. Since the mail-enabled user has had the legacyExchangeDN modified, and the only replica of the External free/busy folder is on Exchange 2010, the Exchange 2003 Public Folder database will issue a referral to the client to the Exchange 2010 SP1 Public Folder database, which is where the only replica of that Free/Busy public folder resides. Step 3. Outlook queries the Exchange 2010 SP1 Public Folder for Free/Busy. Microsoft Exchange RPC Client Access Service running on the Mailbox role intercepts the Free/Busy request and routes it to Availability. Step 4 and 5. Exchange 2010 detects it is for a remote org, and detects there is an Organization Relationship. Exchange then validates the Federation Trust. Step 6. Exchange 2010 then sends a request to the Availability service endpoint for Org B. Step 7. The response is generated by the Availability service in Org B and sent back to the Exchange 2010 SP1 CAS server in Org A. Step 8. Microsoft Exchange RPC Client Access Service translates the availability response into a Public Folder free/busy response, and returns the information to the Outlook client. In addition, the availability response is placed into the Free/Busy Public Folder and cached for 15 minutes. If additional availability queries are performed for that remote user within that 15 minute period, they will be returned from the cache. Known Issues/Concerns Issue #1 - OWA 2003 When Exchange 2003 users use OWA to schedule a meeting, they will look at “Availability” tab in the form, which will request free/busy from public folders via DAV. A free/busy request for DAV looks like this: http://ExchangeServer/public/?Cmd=freebusy& start=2009-10-28T00:00:00-07:00& end=2009-10-29T00:00:00-07:00& interval=30& mbxguid=ea14502f-44cc-41ae-9f1d-df519a16ad20& u=SMTP:mary@Contoso& u=SMTP:joe@Contoso.com Note: The above text is actually a single line string, it was broken down into multiple lines for easy reading. DAV can only retrieve free/busy for users in the local public folder database. When OWA loads pages and scripts in the browser, it passes the URL to the public folder corresponding to the user mailbox. If the is no local replica for the folder corresponding to the first user provided in u= entry in the URL, DAV will do HTTP redirect (status 302) for the entire request to a public server that has that replica. Note this implementation assumes that free/busy for all other users provided in the request can also be found in the same server. The implication is that free/busy folders for different administrative groups must have replicas in all public folder databases. In our case, some or all free/busy folders will only have replicas on Exchange 2010, however Exchange 2010 does not support the DAV protocol, so OWA redirects to 2010 will simply fail. With Option A, this will cause ALL OWA Free/Busy requests (both internal and external) to fail, as the Exchange 2003 server will not have replicas of any Free/Busy public folders. With Option B, if the free/busy request is for a local mailbox user, the request will succeed. If the request is for a user from the remote org, the request will fail. Issue #2 - Internal Free/Busy for Exchange 2003 Option A for Exchange 2003 requires that the only replicas for all free/busy folders must reside on Exchange 2010 SP1 servers. In environments where Exchange 2003 Public Folder databases are located in multiple physical sites, if Exchange 2010 Sp1 Public Folder databases are not located in the same physical sites, this may lead to issues with excessive latency and possible performance issues as internal free/busy queries may have to traverse WAN links. Issue #3 - Queries for Exchange 2007 users cross-org fail By default, Exchange 2007 allows availability queries for 42 days of information. Exchange 2010 bumped up that limit to 62 days. When Exchange 2010 performs the request for a user on Exchange 2007 in the remote organization, the request may fail because Exchange 2010 is requesting 62 days of information, which exceeds the default limit of 42 imposed by Exchange 2007. To address this issue, you can adjust the maximumQueryIntervalDays value in the EWS web.config (located in the \Program Files\Microsoft\Exchange Server\ClientAccess\ExchWeb\ews\ folder) on the Exchange 2007 servers. Add the value under the AppSettings section. This example configures the availability service on Exchange 2007 server to provide availability information for 62 days. <appSettings> <add key="maximumQueryIntervalDays" value="62" /> </appSettings> Note: The maximumQueryIntervalDays value is not present by default. If this value is not present, Exchange uses the default interval of 42 days. After you do this, you will want to do an IISReset on the Exchange 2007 CAS servers to make sure the new setting takes effect, as this value is only read on startup. Issue #4 - Queries for Exchange 2003 users cross-org fail By default, an Exchange 2010 CAS performing a cross-org free/busy lookup will query the autodiscover service for the user you're attempting to view Free/Busy for. If the target user is an Exchange 2003 user, autodiscover will fail because Exchange 2003 users are not autodiscover-enabled. This issue is scheduled to be fixed in Exchange 2010 SP1 Update Rollup 4. To work around this issue, manually set the targetSharingEPR on the Organization Relationship for the remote organization with Exchange 2003. Example: Set-OrganizationRelationship –identity -targetSharingEPR https://mail.contoso.com/ews/exchange.asmx/WSSecurity Update: The issue has been fixed in Exchange 2010 SP1 Update Rollup 4. See KB 2506820. The free/busy information does not display of a user whose mailbox is located on an Exchange Server 2003 server. An additional issue with queries for remote Exchange 2003 users is that the remote organization will return the Free/Busy response in the format of a MergedOnly string. Exchange 2010 cannot convert this string to store the result in public folders, so no information is returned to the Outlook client. A fix is available for this issue. See KB 2567863 Free/Busy information may not be returned when a Cross-Org query is performed from a legacy Exchange user. Issue #5 - Federating with another Organization that has both on-premises and cloud users If you federate with another organization that subscribes to a cloud service such as Office 365 or BPOS , availability lookups for remote users that have been moved to the cloud will fail. The reason is that your organization relationship is with the on-premises Organization. That on-premises org has a completely separate Organization Relationship with O365/BPOS. When an availability call is made from a separate org via an Organization Relationship, it'll be made to the on-premises org, where a mail-enabled user or contact will be found. There's no functionality to proxy the availability call through the Organization Relationship from the on-premises Org to the cloud, so this call will fail. Ben Winzenz
