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.
