calendaring
26 TopicsConfiguring 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.285KViews20likes85CommentsResource scheduling in Exchange Server 2007
Update 4/16/2009: We have corrected an incorrect permissions entry in this blog post. Heard of the term calendar concierge? Look up http://msexchangeteam.com/archive/2006/07/24/428390.aspx. In this post I'm going to talk about what happened to the Auto Accept Agent in Exchange Server 2007 and how you can define, schedule and manage resources easily and reliably. Booking resources (e.g. a conference room) in conjunction with a meeting frequently leads to multiple meeting updates, general confusion and lost productivity for both organizers and attendees. The system should enable organizers to reliably find and book an available resource in one attempt and later confirm the reservation while minimizing attendee confusion. This is accomplished in Exchange Server 2007. Exchange Server 2007 helps the Information Worker quickly find a room at the right time and schedule it. It helps minimize the effort that resource managers must undertake to manage a resource schedule. Help resource administrators control who can schedule resources. Resource booking in Exchange 2003 In Exchange 2003 there are two ways for customers to automate resource booking using Outlook and Exchange: Exchange 2003 Auto Accept Agent and Outlook direct booking The Auto Accept Agent (AAA) is a server-side store event sink available in the Exchange 2003 SP1 timeframe. It provides automatic server-side processing of meeting requests sent to resource mailboxes that have been registered with the agent. The agent handles both requests and cancellations and sends responses to the meeting organizer. AAA uses EXOLEDB and CDOEX for notification of incoming messages and calendar item processing, respectively. Direct booking is an Outlook-specific feature that uses the organizer's Outlook client (Outlook 2000 or later) to book an appointment directly into a resource mailbox schedule. The Outlook client of the person organizing the meeting performs all the necessary tasks, such as conflict checking and placing the reservation on the resource calendar. The resource mailbox must be manually configured with Outlook to support direct booking. It can be set up to allow automatically accept non-conflicting meeting requests and to allow/deny recurring bookings. What's new in resource booking in Exchange 2007? Exchange 2007 provides a reliable resource management solution that maps to information worker goals and increases organizational productivity. Exchange Server 2007 introduces changes to the resource booking architecture that address many of the concerns. Resource management improvements have been made in the following areas. Booking and search services Up-to-date Free/busy Integration with Office Outlook 2007 meeting request process Schedule management services Ability to delegate management of resource policy to users using Outlook Web Access Policies and rules to control who can schedule and when they can schedule Support for both manual and automatic approval Enterprise-wide resource management services Ability to create and manage resource schema Resource Booking Attendant Exchange 2007 identifies meeting resources as either a room or equipment and includes special attributes for each of these types of resources. For example, a room resource includes a capacity attribute. Custom attributes, such as audio-visual capabilities can also be defined. The Resource Booking attendant provides the following features: Enforces maximum meeting duration Schedules meetings only during working hours Forwards out-of-policy requests to delegates for approval Provides conflict information for declined meetings Feature Comparison The following table shows a comparison of the features available for direct booking in Outlook, using the Auto Accept Agent, and resource scheduling in Exchange Server 2007. Feature Outlook Direct Booking Auto Accept Agent Resource Scheduling Booking Process Directly books without sending mail x Resource can be designated as any type of attendee x x Does not require permissions to calendar folder of resource x x Resource schema Distinguish between user and resource mailboxes in GAL/OAB x Find resources based on resource criteria (location, custom property) x Add additional, custom resource properties x Resource administration Integration with Exchange Management Console and Shell x Scheduling Logic Return information on conflicts in recurring meetings x x Prevent double booking x x x Partially book recurring meeting x x Strips sensitive information from request, calendar item x x Scheduling Policy Define list of users who can book directly x x Control how far requests are booked in the future x x Define list of users who can book with approval, book outside policy x Set available hours, max duration x Custom meeting response text* x x *Its per server in AAA and per mailbox in Exchange Server 2007 Steps to set up Resource booking in Exchange 2007 Before going further I want to explain a few points one should be aware while working with a resource mailbox in Exchange Server 2007. A resource mailbox has the same structure as a user mailbox - it is composed of an Active Directory mailbox-enabled user object and an Exchange mailbox. The major difference between a user and resource mailbox is that the resource mailbox: Always has special resource-specific properties set on the Active Directory user object. Typically has a disabled user account and grants logon privileges to one or more "resource managers" May have a scheduling policy automatically enforced by the Resource Booking mailbox assistant. I will talk more above Exchange Server 2007/Exchange server 2003 environments and how legacy resource mailboxes can be converted to Exchange Server 2007 resources without interrupting the ability of legacy clients to send meeting requests to them later on. In this post I'm going to concentrate on a pure Exchange Server 2007 environment. Resource mailbox scheduling and administration in Exchange Server 2007 is primarily handled by the Resource Booking Attendant. The calendar and Resource Assistant interact with each other. The Resource Assistant provides a call that determines if a mailbox is a resource or not. 1. Create a new mailbox. This can be done either from the Shell (Powershell/Exchange Management Shell) or by using the EMC . Create a new mailbox using the EMC : Expand Recipient Configuration > select Mailbox, and then click New Mailbox in the Mailbox section of the Actions task pane. Figure 1: Click New Mailbox to start the New Mailbox Wizard Note: In Exchange 2007, only disabled accounts can be used as resource mailboxes. When you create a new resource mailbox, the user account is disabled by default. If you click Existing User and then Browse, only disabled accounts are presented. Enabling the user account for a resource mailbox is NOT a supported configuration. Use the Shell to create a new mailbox: New-Mailbox -Name:"Resource1" -Alias:Resource1 -OrganizationalUnit:Users -Database:"Database Name" -UserPrincipalName:"Resource1@domain.com" -DisplayName:"Resource Mailbox" -Room If you use the EMC , the end result is the same. In the final page of the wizard, the EMC actually shows you the Shell command that it uses. Figure 2: The final page of the New Mailbox Wizard shows the Shell command used This will create a new resource mailbox mailbox. At the command prompt type Get-Mailbox Resource1 | fl *resource* The output: IsResource : True ResourceType : Room Notice the ResourceType is Room. At this point, the resource mailbox is not completely configured. If you attempt to book the resource it will not automatically accept the meeting. After creating a resource mailbox, you'll need to configure it to auto-accept meetings to which the resource mailbox has been invited. Otherwise, the resource mailbox does not automatically accept meetings sent to it and meetings sent to it will sit in the calendar of the resource in a "tentative state". Note: To learn more about the Format-List cmdlet (the short form or alias fl is used here), please see this. Additionally, piping the output to fl *resource* will display all the attributes (of that mailbox) where the attribute name contains the string resource. Let's check calendar settings for the mailbox: Get-MailboxCalendarSettings Resource1 | fl The output shows that AutomateProcessing is set to AutoUpdate by default: AutomateProcessing : AutoUpdate If AutomateProcessing is set to AutoUpdate (the property that controls the automatic acceptance of meeting requests), then the meeting organizer receives no response from the resource. In order to accept a meeting, one would have to log into the resource mailbox (using an account that has permissions to access the resource mailbox) and accept it. 2. Enable Auto-Accept for a resource and configuring resource mailbox settings Using OWA or the Shell, you can configure a mailbox to automatically process meeting requests and cancellations. Using the Shell: Set-MailboxCalendarSettings Resource1 -AutomateProcessing:Autoaccept Get-MailboxCalendarSettings Resource1 | fl The output: AutomateProcessing: AutoAccept Using Outlook Web Access You can log on to the resource mailbox using OWA and configure the resource account to automatically process meeting requests and cancellations from the Options page. What account do you use to log into OWA? Because the account for a resource mailbox is disabled, you can use either of the following methods to log into the resource mailbox using OWA: Explicit OWA logon to the resource mailbox with credentials for an account that has FullAccess permissions to the mailbox. Use this command to grant FullAccess permissions to User1 for the Conference Room1 resource mailbox. Add-MailboxPermission -Identity:Resource1 -AccessRights:fullaccess -User:user1 After User1 has been given FullAccess rights, in your browser, enter the explicit URL for the resource mailbox: http://servername/owa/Resource1@domain.com. When prompted for credentials, enter the username and password for an account that has FullAccess permission to the resource mailbox - in this case User1. Log into OWA using an account that has has FullAccess permissions to the resource mailbox and select Open Other Mailbox. Enter the normal URL for OWA: http://servername/owa When prompted for credentials, enter the username and password for an account that has FullAccess permissions to the resource mailbox. In the upper right corner of the OWA page, click the dropdown next to the logged on username, select Open Other Mailbox and then enter the name of the resource mailbox. Figure 3: Select Open Other Mailbox to open another mailbox in OWA When you log into a resource mailbox, click on Options and notice Resource Settings on the left pane as an available option just for resource mailboxes. You can set the following options on this page. Every single option via the shell is available on this page. Resource Scheduling Options Resource Scheduling Permissions Resource Privacy Options and Response Message Scheduling a Room Resource Exchange 2007 creates an All Rooms address list as seen in the following screenshot: Figure 4: Exchange 2007 creates an All Rooms address list by default In Outlook 2007, the All Rooms search feature transpires itself as shown below. Instead of clicking the To" button, which is everything in the GAL , you can now click on Rooms and we come up with the All Rooms address list. If you select a room, it automatically adds it in the Resources well. This should work if the resource is added to the "Required" field. Figure 5: Selecting Rooms when scheduling a meeting, Outlook 2007 displays all rooms from the Rooms address list Managing Resource Scheduling If you want to lock down the resource booking options, you have the option to do so. Let's take a look at a few of the options available to lock down resource mailboxes. Open up the shell prompt and type: Get-MailboxCalendarSettings Resource1 | fl Take a look at the different parameters that can be set for a resource mailbox. Most of the parameters are self-explanatory. Let's focus instead on some of the policy-based settings, such as RequestInPolicy, BookInPolicy, RequestOutOfPolicy, AllBookInPolicy, AllRequestOutOfPolicy, etc BookInPolicy: List of users/groups that can submit an in-policy request for automatic approval - Value is a String: SMTP address; series of SMTP addresses RequestInPolicy: List of users/groups that can submit an in-policy request that is subject to approval by a resource mailbox delegate. - Value is a String: SMTP address RequestOutOfPolicy: List of users/groups that can submit an in-policy request for automatic approval; Out-of-policy requests are subject to approval by a resource mailbox delegate. The RequestOutOfPolicy setting is good for situation where certain users (CEO for example) that should never receive an automatic meeting decline. - Value is a String: SMTP address The default options allow all users to book resources if they are within the set policies (i.e. up to 180 days in the future, up to 1440 minutes in duration, etc.), and will reject all other meetings. In the context of resource mailboxes, InPolicy and OutOfPolicy simply mean whether or not the meeting invitation matches any restrictions enabled on the resource mailbox. For example MaximumDurationInMinutes value for the resource mailbox is 30 minutes, any meeting invitation longer than 30 minutes would be considered OutOfPolicy. Using the RequestOutOfPolicy parameter, you can manually add users that are allowed to request meetings that are not within the policy, and if you really want to lock things down, you can set the AllBookInPolicy value to False, and then manually add users to the BookInPolicy field, or more restrictive, to the RequestInPolicy field. By default, the BookInPolicy parameter is configured for Everyone. If you leave BookInPolicy with the default setting and you configure the RequestInPolicy parameter with one or more SMTP addresses, the BookInPolicy setting overrides RequestInPolicy. The meeting is automatically accepted if it is within policy. Compared to the options that were available with Auto Accept Agent, these settings allow you a lot of control to lock down and customize resource booking permissions. You can't use the EMC to set resource booking policies. To run the Set-MailboxCalendarSettings cmdlet, the account you use must be delegated Exchange Organization Administrator role. How to Set Resource Booking Policies To control who can schedule a resource, use the following parameters in conjunction with the Set-MailboxCalendarSettings command: AllBookInPolicy, AllRequestInPolicy, AllRequestOutOfPolicy, BookInPolicy, RequestInPolicy, RequestOutOfPolicy, ForwardRequestsToDelegates, TentativePendingApproval, ResourceDelegates To control when a resource can be scheduled, use the following parameters in conjunction with the Set-MailboxCalendarSettings command: AllowConflicts, BookingWindowInDays, EnforceSchedulingHorizon, MaximumDurationInMinutes, AllowRecurringMeetings, ScheduleOnlyDuringWorkingHours, ConflictPercentageAllowed, MaximumConflictInstances To control what meeting information will be visible on the resource's calendar, use the following parameters in conjunction with the Set-MailboxCalendarSettings command: DeleteAttachments, DeleteComments, RemovePrivateProperty, DeleteSubject, DisableReminders, AddOrganizerToSubject, DeleteNonCalendarItems, OrganizerInfo To customize the response message that meeting organizers will receive, you can use the following parameters in the Set-MailboxCalendarSettings command: AddAdditionalResponse, AdditionalResponse Here's how "Restricting who can book" will look like: More information regarding booking policies can be found in Set-MailboxCalendarSettings cmdlet help. How to Customize the Response Message for Resource Scheduling To use the Exchange Management Shell to customize the response message for resource scheduling, run the following command Set-MailboxCalendarSettings -Id ResourceMailbox01 -AddAdditionalResponse:$true -AdditionalResponse:<text> As an example: Set-MailboxCalendarSettings -Identity "ResourceMailbox01" -AddAdditionalResponse "Add your response text here" You can also set a custom response through OWA as mentioned previously. Figure 6: Creating a custom response message using Outlook Web Access How to Set a Delegate on a Resource Mailbox In the context of resource mailboxes, the term delegate is used very loosely. You do not use the Delegates tab in the Outlook Tools > Options dialog box to configure the delegate even though the user(s) managing the resource mailbox might appear on the Delegates tab. These users appear on the Delegates tab because they have Send-on-behalf permissions to the resource mailbox. In scenarios where you are using the AllRequestOutOfPolicy, RequestOutOfPolicy, AllRequestInPolicy, or RequestInPolicy parameters, you need to use a delegate to respond to meetings that are not automatically accepted or declined by the resource mailbox. Note: If you don't want to forward requests to a delegate (ForwardRequestsToDelegates = false), you can get away with granting FullAccess permissions for the resource mailbox to a regular user. This user can respond to meeting invites from the Inbox of the resource mailbox. Because resource mailboxes use disabled accounts in Exchange 2007, the steps to create a delegate for a resource mailbox are a little different than in earlier versions of Exchange. To configure a delegate for an Exchange 2007 resource mailbox, use the following steps. Run a command similar to the following to specify the delegate for the resource mailbox. Set-MailboxCalendarSettings Resource1 -ResourceDelegates Delegate1 Note: Because of a bug in ResourceDelegates, the complete permissions for the delegate are not added to the resource mailbox. This is fixed in Exchange 2007 SP1. Therefore, you must also perform one the following methods to provide the necessary permissions to the delegate. Use either of the following methods to provide adequate permissions on the resource mailbox to the delegate: Method 1: Provide Full Access permissions to the delegate Assign FullAccess mailbox permission for the resource mailbox to a delegate: Add-MailboxPermission Resource1 -AccessRights FullAccess -User Delegate1 Method 2: Modify the Free/Busy Permissions for the resource mailbox To modify just the free/busy permissions on the Resource mailbox, use the following steps: Assign FullAccess mailbox permission for the resource mailbox to an administrator: Add-MailboxPermission Resource1 -AccessRights FullAccess -User Admin1 Create an Outlook 2007 profile for the resource mailbox. Start Outlook with this new profile and provide the credentials of the Admin1 user when prompted. Note: Granting an administrator user Full Access permission instead of the delegate is a technique you can use for central administration of resource mailboxes. This allows the administrator to gain access to the resource mailbox while also allowing the delegate to process meetings for the resource. Right-click the Calendar folder and click Properties On the Permissions page, make sure the delegate (a user other than the administrator Admin1) has at least Editor permissions to the Calendar folder. Click OK. Exit Outlook. Now check the delegates on the resource mailbox using this command: Get-MailboxCalendarSettings Resource1 |fl It should now show: ResourceDelegates : {Delegate1} The default setting for the ForwardRequestsToDelegates parameter is true. Therefore, meetings are forwarded to the delegates (listed under ResourceDelegates). If this is set to false, the delegate will not receive the forwarded invite. Happy resource booking in Exchange Server 2007. Nagesh Mahadev130KViews0likes24CommentsHow to publish Anonymous Calendar Sharing URL in Exchange Online or Exchange 2013
Do your users want to share their calendar with anonymous users? Here's a tip related to sharing your calendar via a web link for anonymous users (users outside of your organization). Users can publish their calendar for anonymous viewers using OWA . Organization administrators can also publish a user's calendar. Here we will share both of those ways. Note: Publishing your calendar for anonymous users allows anyone with the link to the calendar to view it without having to log-on. Publish your calendar using OWA Publishing your calendar: Log on to OWA and go to Calendar. Right click the calendar you want to share and choose permissions: Change the permissions drop-down from “Not Shared” (Default) to “Availability only” (or whichever permission you intend to grant) and press Save: Retrieve the link to share it with users outside of your organization: Right click Calendarpermissions > and then View Calendar. This will bring up a browser window with the sharing link (URL). You can also right click on the View Calendar link and then select Copy Shortcut to get copy the link. You can send the link to users outside your organization to allow them to view your calendar Controlling anonymous calendar sharing in your organization Administrators can control whether users can share their calendar with anonymous users outside the organization. If users try to share the calendar when anonymous calendar sharing is not allowed in their organization, they get an error. Administrators must configure a sharing policy to allow users to share their calendar with all domains. For details, see the following articles: Managing Federated Sharing with the EAC Office 365: Sharing in Exchange Online Exchange 2013 on-premises: Sharing Publish a user's calendar (as an organization administrator): If you're an organization admin, here's how you can publish the calendar of a user or a resource/room using PowerShell. Run Set-MailboxCalendarFolder <Username>:\Calendar -PublishEnabled $true Run Get-MailboxCalendarFolder <Username>:\Calendar |fl or Get-MailboxCalendarFolder <Username>:\calendar |fl publishedcalendarurl. This will output the published calendar html (and ics) urls. Others can use this url to view the publisher’s calendar. Example: PS C:\Windows\system32> set-MailboxCalendarFolder calroom1:\calendar -PublishEnabled:$true PS C:\Windows\system32> Get-MailboxCalendarFolder calroom1:\calendar RunspaceId : 0f40e5da-5712-4043-8bbc-fb11049c0307 Identity : calroom1:\calendar PublishEnabled : True PublishDateRangeFrom : ThreeMonths PublishDateRangeTo : ThreeMonths DetailLevel : AvailabilityOnly SearchableUrlEnabled : False PublishedCalendarUrl : http://outlook.office365.com/owa/calendar/6eba91c3eb20499fabc3d831f38b961b@contoso.com /5c3a873ee338449bb7d39dd2f7280b933185741279014858945/calendar.html PublishedICalUrl : http://outlook.office365.com/owa/calendar/6eba91c3eb20499fabc3d831f38b961b@contoso.com /5c3a873ee338449bb7d39dd2f7280b933185741279014858945/calendar.ics IsValid : True ObjectState : Unchanged For more on other calendar sharing options in Exchange Online, please look at thispage. Sathish Venkat Rangam Updates 4/15/2014: Added se ction about sharing policies.106KViews0likes8CommentsExchange 2010 Calendar Repair Assistant
Exchange 2010 had many new enhancements and improvements over prior versions of Exchange. One really cool feature was the introduction of the Calendar Repair Assistant (CRA). The CRA is a mailbox assistant that is configurable through the Exchange Management Shell and runs within the MS Exchange Mailbox Assistants service. Its intended purpose is to help maintain consistency of calendar meetings between an organizer and the attendees by comparing the meeting copies of the organizer and the attendees. Why did the Exchange Product Group build this really awesome component into Exchange 2010? I’m glad you asked. I want to take you on a journey back to…The Good Ole Days! The Good Ole Days In the “Good Ole Days” (or even as recently as last week), the Exchange support team logged numerous calls and cases on calendar meeting issues for prior versions of Exchange. Because of the flexibility allowed in terms of what end users can do with meetings in their calendars, meetings can become inconsistent across organizers and attendees calendars. These issues would range from inconsistent meeting times between organizers and attendees to meetings being “unknowingly” deleted from a user’s calendar. We saw cases where meetings would show up in Outlook but not a mobile device or vice versa. Sometimes meetings would be duplicated on a calendar or would lose their organizer. Delegates would reportedly make a change to a meeting but it wouldn’t show up on the mailbox owner’s mobile device. The list goes on. The troubleshooting of these issues, though normally pretty straight forward can be tedious and time consuming. I went ahead and included a troubleshooting reference guide for you below not only to point out how we would troubleshoot and identify these problems, but also just in case you’ve stumbled onto this blog and you’re experiencing something similar! Exchange calendar troubleshooting reference Getting to the most recent service pack and update of your Outlook client and Exchange Server is very important as doing that might actually address your reported problems. Depending on the type of issue you are experiencing, there are several different ways to troubleshoot. If you are trying to determine why a meeting keeps changing or is moved to the deleted items folder, etc. MFCMapi is a good tool to use. You can launch MFCMapi and connect to the mailbox profile of the user that is reporting the issue. Find the calendar item that you are looking for and save out the properties of that item to a text file. Search for the PR_LAST_MODIFIER_NAME, PR_LAST MODIFIED_DATE, PR_SENDER_EMAIL, and PR_SENT_REPRESENTING_NAME. These properties will paint a pretty good picture for you. Often times we’ve seen that the last user to modify the item is either a service account for a MAPI/CDO device, a delegate, or the mailbox owner themselves. Another great tool you can use to see what is happening to a meeting is Exchange Trace or “Trace Control” which can be found in the Exchange Troubleshooting Assistant in Exchange 2007 and 2010. You can setup your trace, check all of the boxes under “Trace Types” and then on the “Components to Trace” you will select “Store” with the following “Trace Tags”: tagCalendarChange, tagCalendarDelete, tagMtgMessageChange, tagMtgMessageDelete. You can then setup a mailbox filter for the mailbox in question and kick off the trace. At this point you will need to reproduce the issue (or wait until it reproduces). Once it does stop the trace. You’ll need to get with Microsoft support at this point to convert and analyze the trace for you. One of my colleagues over on the Outlook team, Randy Topken, created a great tool called CalCheck. It performs a wide variety of tests and is very helpful in troubleshooting Calendar issues. I won’t go through all of them as he has published everything you need to know here: CalCheck - The Outlook Calendar Checking Tool. There are many other issues that we have encountered, but this is a glimpse of the most common types of issues we have seen (and actually continue to see) and how we go about troubleshooting those problems. Hopefully this gives you a little insight as to why we were so excited to see the Calendar Repair Assistant in Exchange 2010. I’ve included some additional links to assist you in troubleshooting calendar below: Working with support to troubleshoot the Outlook calendar in an Exchange environment How to troubleshoot calendar issues in Microsoft Outlook, Microsoft Exchange Server 2007, and Microsoft Exchange Server 2010 How to troubleshoot missing and duplicate appointments in Outlook Troubleshooting Free/Busy Information for Outlook 2007 CRA RTM Now let’s get to the heart of this article, THE CRA! The CRA was built to detect and correct calendar inconsistencies like I described above between a meeting organizer and attendees. The CRA must be configured through the Exchange Management Shell in order to run, as it is not enabled by default. Once enabled, the CRA will run against all mailboxes on the server you have configured it for. You can disable it for specific mailboxes by using the Set-Mailbox cmdlet and setting the CalendarRepairDisabled to True. In the RTM release of Exchange 2010, the CRA was a time-based assistant that was configured to run on a specified schedule and could not be throttled to adjust for server resource utilization. CRA made decisions only by comparing an organizer’s copy of a meeting with the attendee’s copy of the meeting. CRA uses the organizer’s meeting copy as the master and assumes it is the correct copy. It then checks attendee response status and assumes that the attendee’s response status is correct and updates the tracking information for the organizer. The problem was that CRA had no idea of how the inconsistencies occurred, meaning it didn’t take into account client intent i.e an attendee intentionally changes a meeting start time or location on their own calendar. One of the biggest issues we saw with this lack of client intent checking in RTM was if an attendee deleted a meeting from their calendar but did not send an update to the organizer, the CRA would recreate the meeting in the attendees calendar and would continue to do so until the attendee sent a response to the organizer (this has been corrected in SP1). When the CRA detects an inconsistency on a calendar, it issues a special meeting message called a Repair Update Message. The message is processed by the Calendar Attendant and then the message is placed in the user’s Deleted Items folder. Any repairs made are recorded in the CRA log (see Troubleshooting CRA below). CRA SP1 and later Exchange 2010 SP1 saw some pretty cool changes to the CRA. As mentioned earlier, in the RTM version CRA was time based and ran on a specified schedule. In SP1 and later this changed to a throttle based assistant to help prevent it from impacting server resources or end user experience. You can enable CRA with the Set-MailboxServer cmdlet. You will need to set the CalendarRepairWorkCycle and the CalendarRepairWorkCycleCheckpoint. The work cycle is the time span allocated for CRA to scan and process all mailboxes on the server i.e. if this is set to seven days, that means every mailbox on the server will be processed once every seven days. The throttling assistant calculates the slowest pace at which mailboxes can be processed by dividing the total number of mailboxes by the work cycle. There is also a built in mechanism to monitor certain resources like store and throttle the processing back if the load starts to rise. The checkpoint is the period of time in which the list of mailboxes in the CRA’s queue is refreshed during the existing work cycle, adding new mailboxes, moved mailboxes and mailboxes that have not processed yet into its queue. For example, the following command will set the CRA to check all mailboxes on the server once every seven days and refresh its work queue every day with the list of calendars that still need to process repairs within that seven day period: Set-MailboxServer –Identity MBXSRV1 –CalendarRepairWorkCycle 7.00:00:00 –CalendarRepairWorkCycleCheckPoint 1.00:00:00 You can verify the settings for calendar repair options that are set for all mailbox servers by running the following in Exchange Management Shell: Get-MailboxServer | fl name,*calendar* Another great change in SP1 was the introduction of “client intent”. The CRA can now distinguish intentional versus unintentional inconsistencies between a meeting organizer and attendees. When the CRA is running against an attendee calendar, it will validate a meeting item against the organizer’s copy. If it is running against the organizer, it will validate the item against all attendees. The CRA will correct inconsistencies, but only for mailboxes on the server for which it is running. It reads from other Exchange 2010 mailbox servers, but each server enabled for calendar repair will have its own instance of the CRA running that is responsible for the mailboxes on that server. When the CRA finds an inconsistency, it goes about determining client intent by using snapshots of calendar items that are stored in something called the Calendar Version Store (CVS) and calendar metadata. Before a calendar item is changed, the Exchange 2010 copy on write functionality takes a snapshot of the calendar item and stores it along with additional metadata (like the source or the application that initiated the change) in the root of the Recoverable Items folder for a default 120 days before being purged. The Calendar Version Store maintains a historical record of these calendar item snapshots that are in the Recoverable Items folder. Client intent metadata is added to a calendar item as a named property: Name id = 0x0015 (dispidClientIntent), Named Prop GUID = 11000E07-B51B-40D6-AF21-CAA85EDAB1D0. Any non-zero Hex value represents an intentional change. Before a specific change is made to a calendar item, the snapshot is taken which preserves the existing metadata as well. When the CRA is determining client intent, it queries the Calendar Version Store. During the initial query, a special dynamic search folder is created called CalendarVersionStore in the root of the non-IPM subtree with a search scope of the IPM subtree and the Recoverable Items folder and criteria of all calendar items and meeting messages. Once this search folder is populated with the requested stored versions of a particular item from the Calendar Version Store, the CRA will go about determining client intent. It must first determine the target version of the particular item. It does this in one of two ways. The first method the CRA uses to determine the target version for client intent is when the resulting change, and not the state prior to the change, is important, ie an item is deleted. The Calendar Version store is sorted with the most recent item on top and then queried backwards. The oldest version found that is in the target state is used as the target version and it is the one whose client intent metadata is validated. Let’s say that item A is deleted and there are 4 snapshots of item A in the CVS. We will call them A4-A1. First A4 is queried and we see that it matches the target deleted state. Then A3 is queried and (for hypothetical purposes) we see it is also in the target deleted state. Then A2 is queried and the CRA determines that this snapshot is not in the target deleted state. Now the CRA will go back to A3 and review the metadata on it for client intent. Any non-zero entry on this item indicates an intentional change. The second method the CRA uses to determine the target version for client intent is when how an item transitioned into a certain state is important, ie the time or location on an attendee copy is different from the organizer’s copy. The main difference of this method is that it looks at the chain of snapshots from initial state to target state. If any snapshot in the chain does not show client intent, then the whole change is considered unintentional. Let’s say that the CRA finds that a meeting attendee for meeting B has a different time listed than the organizer. There are 5 snapshots of B in the attendees CVS, B5-B1. The CRA searches backwards (B5-B4-B3-B2-B1) and finds that B2 is the last snapshot with the same time as the organizer. It will then look at the metadata on B3-B5. If any of these have a zero entry, the entire chain is considered unintentional and will be corrected. All of the items in this chain must have a non-zero metadata client intent property value set for CRA to read this as an intentional change. In 2010 SP1, when the CRA detects an unintentional inconsistency it uses the same process (Repair Update Message) as it did in 2010 RTM. When the CRA detects an intentional location or time inconsistency, no repair action is taken on the calendar item. If there is an intentional missing organizer or attendee item, the CRA uses a special inquiry message to repair the item on the opposite calendar. For instance, if a meeting organizer deletes a meeting but doesn’t send out a cancellation, the meeting will still exist on the attendee’s calendar. The CRA will send a special inquiry message that is processed by the calendar attendant and trigger a normal meeting cancellation on the attendee’s calendar. For more information on CRA conflict detection and resolution logic see the “Conflict Detection and Resolution” section here: Understanding Calendar Repair Caveats CRA does not run against resource mailboxes. If the meeting organizer does not enable the “Request a response to this invitation” in OWA or “Request Responses” option in Outlook, calendar repair will not take place on that meeting. If you set calendar repair to disabled for a specific mailbox, calendar repair will not take place for that mailbox. You can verify this with get-mailbox | ft name,CalendarRepairDisabled . If it’s set to true, then calendar repair is disabled. If you disable the Calendar Version Store for a specific mailbox, then client intent cannot be determined. You can verify this get-mailbox | ft name,CalendarVersionStoreDisabled . If it’s set to true, then the Calendar Version Store is disabled. The CRA only check calendar items for mailboxes that have the calendar attendant enabled (it is by default). This allows the Repair Update Message to be processed. See Set-CalendarProcessing. The primary clients that write client intent metadata are OWA 2010 SP1 and Outlook 2010. Client intent for clients utilizing EWS or EAS may be limited. See Client Application Experience. CRA will not change the meeting organizer, if it has been improperly changed. Troubleshooting CRA Troubleshooting calendar issues in 2010 can be approached in the same way as listed in the earlier troubleshooting section. There are some additional things you can look at when trying to see if the CRA processed a repair to a meeting and why. The first is the CRA log. It is stored on the mailbox server that it is running on and is located in <ExchangeInstallPath>\Logging\Calendar Repai r Assistant and is in the format of CRA<date>yyyymmdd-<sequence>.<user>.log. Locate the CRA logs for specific users and then review them for any repairs that the CRA made. get-CalendarDiagnosticLog can be used to search the Calendar Version Store for a particular user and a particular item. Then you can use MFCMapi as outlined above to search the properties of the item and determine if there was positive client intent. Conclusion Hopefully I’ve shed a little light on the importance of the Calendar Repair Assistant. It is a critical component and has, in my opinion, reduced the number of cases in Exchange 2010 than what we saw for calendar issues in prior versions of Exchange. Troubleshooting, while you can still use the same techniques used in legacy versions of Exchange, has been simplified with the CalCheck, Calendar Repair Log, and using the Get-CalendarDiagnosticLog to pull calendar items from the Calendar Version Store for analysis on client intent cases. Additional resources Understanding Calendar Repair Configure Calendar Repair Assistant Settings Managing Calendars Set-MailboxServer Set-Mailbox Changes to Recoverable Items Versioning in Exchange 2010 SP2 RU3 I wanted to thank Mike Manjunath, Rob Whaley and Jonathan Runyon for their review of this blog post. Charles Lewis101KViews0likes10CommentsCross 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 Winzenz61KViews0likes4CommentsCommon 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 Bilic54KViews0likes12CommentsThe Hybrid Free Busy Troubleshooter Now Available
Hybrid Free/Busy troubleshooter As customers move their organization into the Cloud or choose to coexist, there is a need to ensure that some of the basic functionalities users have grown accustomed to, continue to work. While some of you will move all of the users in a cutover fashion which reduces complexity, others will choose a more gradual approach. This troubleshooter is for administrators that have chosen the hybrid approach. Are you seeing the hash marks in your hybrid Exchange environment as depicted below and want to get rid of them? Then this troubleshooter is for you. The reason we focused on a troubleshooter for Free Busy is because it is the most commonly used “feature set” in a hybrid deployment. If you were to resolve issues with Free Busy lookups, many of the other potential issues you have with your hybrid deployment would be resolved as well. What is a Hybrid Deployment? A Hybrid Deployment consists of an on-premises Exchange server environment that has at least one Exchange 2010 or Exchange 2013 server. In this environment there is also a DirSync (Directory Synchronization) server, and in many cases, a deployment of ADFS (Active Directory Federation Services) to provide single sign-on capabilities to the users. The idea of the hybrid environment is to allow two separate organizations (Exchange Online and Exchange On-Premises) to feel like one organization. To accomplish this, we rely on a token authorization process that is made possible through a combination of Organizations Relationships and Federation Trusts with the Microsoft Federation Gateway. When this is configured properly, you can do basic things like redirect OWA requests to their proper destination, see “MailTips” for a user, and of course the most common feature, view availability information for another user cross-premises. To read more about Hybrid Deployments click here. This sounds hard to configure. How can I avoid issues? If you are the type that does not like running into issues you can attempt to avoid them, all you have to do is deploy using the Hybrid Configuration Wizard and the Exchange Deployment Assistant. These tools have been designed to get you into an optimal Hybrid configuration which should limit the amount of issues you face. However, with all of the moving parts involved and numerous variants in the on-premises deployments you could still run into issues. You may ask, “Why do I need a troubleshooter? I use Bing or I get Scroogled.” When working with customers and engineers, we have found that the troubleshooting steps that need to be followed are not very clear. There is confusion on what steps are applicable when free busy works in one direction (Cloud to on-premises), but not in the other (on-premises to Cloud). While searching Bing for answers can definitely lead to a solution, we believe we can be more expedient by using the troubleshooter to target solutions at your specific symptom. The troubleshooter can be found at the following simple URL: https://aka.ms/hybridfreebusy Thanks to Charlotte Raymundo, Nagesh Mahadev, Edgar Quevedo, John Chappelle, Geoffrey Crisp, Star Li and Chen Jiang for their help in creation and review of this troubleshooter. Timothy Heeney41KViews0likes3CommentsStep by step run of the Exchange Calendar Update Configuration Tool (MSExTMZCFG.EXE)
We have put together a step-by-step walkthrough on how to run the Exchange Calendar Update Configuration Tool (MSExTMZCFG.EXE). This is a server-side tool that can be used as part of the 2007 DST process for Exchange. We have also included some information about solutions for commonly seen errors when running the tool. Please note that the KB article that talks about this package (KB 930879) has additional information about the tool as well as prerequisites and possible complications. There are 2 files that are downloaded in the above package: MSEXTMZ.exe - This file extracts time zone information from mailboxes on a server that is running Exchange Server. This file also updates mailbox calendars for a specified list of users by invoking the Outlook tool against each specified user. MSEXTMZCFG.exe - This file is a configuration tool that describes most of the steps when you update an Exchange Server server. Step 1: Prerequisites to running the Exchange Calendar Update Tool 1) Pick a client operating system. The Exchange tool will run on any of the following operating systems: Microsoft Windows Server 2003 Microsoft Windows XP Microsoft Windows 2000 (must have OS fix or must import registry entries from KB 914387). 2) Install Outlook 2003 or Outlook 2007. Create a profile that has rights to log in to any mailbox in the organization. 3) Install the OS DST Patch (KB 931836). 4) Install the Outlook Time Zone Update Tool (TZMOVE). Download from the Microsoft Download Center or from KB 931667. 5) Make sure that the .NET Framework v2.0 has been installed Now you are ready to proceed. Click on screenshots below to see bigger versions if they are cut off in your browser window. Step 2: Run the MSExTMZCFG.EXE, it opens up like this: The "Server Domain Name" value is the server's LegacyExchangeDN from Active Directory. In order to get this information, you can use the utility such as LDP.EXE or ADSIEdit. The LegacyExchangeDN is in the following format: /o=<Exchange organization name>/ou=<Administrative group name>/cn=Configuration/cn=Servers/cn=<Server name> So something like this: /o=Contoso/ou=First administrative group/cn=Configuration/cn=Servers/cn=E2003BE1 Step 3: Enter the Server Domain Name and press Next: Possible issues at this stage: - You might receive "Please Select the Valid Server" message box if the LegacyExchangeDN is not specified or is not in a valid format (extra spaces would be a problem too). - You might receive the following errors in the MsExTMZ.log due to LegacyExchangeDN mismatch: Unable open mailbox table for server /o=Contoso/ou=First Administrative Group/cn=Servers/dn=E2003BE1. Error 0x80070057. Unable open mailbox table for server /o=Contoso/ou=First Administrative Group/cn=Servers/dn=E2003BE1. Error 80040115. Step 4: Now you will get prompted for the Outlook profile name: Possible issues at this stage: 1. Make sure that you select a profile with administrator privileges and the profile is configured in online mode. 2. You might receive "Unable to find mailbox timezone: Error 0x80004005" (you can check the msextmz.log for errors). This might happen if the mailbox has never been logged into. To resolve this, login to OWA for the user specified in the error message and create a meeting request or an appointment and try re-running the tool again. Step 5: The tool names the text files it will create 1. Conflictusers.txt - this file will contain users that have Conflicting TimeZone entries 2. NonExistent.txt - will contain users who do not have their TimeZone information set. Press Next. Step 6: Specify the Time Zone and paths needed Next you will get to Select Time Zones and specify the path to Outlook.exe and TZMove.exe: Possible issues at this stage: - When specifying the Outlook Time Zone Update Tool, make sure you select the TZMOVE.EXE which is about 304 KB in size rather than the download itself, which is about 8 MB in size. - The TZMove.exe can be found in the following location: C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool - The Outlook registry Path should be pointed to the following location if you are using Outlook 2003 to run the utility: HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook So after you specified the paths you should have something like this: Step 7: Press Finish to finish the configuration After you press Close on the above screen, the Configuration tool creates a folder named by the server name in the C:\MSEXTMZ directory. This folder will contain the following files: Mailboxes_1.txt - This is the list of mailboxes that will be processed when the batch file is run. MSExTmz_1.bat - This is a batch file that will call the C:\msextmz\msextmz.exe to process the MSExtmz_1.ini file MSExTmz_1.ini - This is the INI file which is created by the utility based upon the input specified by us while running steps 1-6 above. If for some reason the update doesn't run, this ini file can simply be modified instead of running through the entire config tool again. NonExistent.txt - This file contains the list of mailboxes which do not have Time Zone Information (like System Mailbox / SMTP Mailbox / System Attendant mailbox etc) or any mailboxes that have not been logged into yet. The folder will look like this: A sample snapshot of MSExTmz_1.bat: A sample snapshot of MSExTmz_1.ini: A sample snapshot of NonExistent.txt: Step 8: run the MSExtmz_1.bat file: Successful processing of the MSExtmz_1.bat will look something like this: All of this information is also being logged into the msextmz.log (as specified in the .ini file). Possible issues at this stage: If you get a bunch of errors with a code of 0x80004005, there are a few things to check: - That the Outlook tool is installed - Make sure the correct TZMOVE.exe has been selected in step #5 above - Try to run the tool from the following location: C:\Program Files\Microsoft Office\Office12\Office Outlook Time Zone Data Update Tool For steps that you should do before and after running of the Exchange tool, other options that you have and related FAQ, please see the Exchange Server and Daylight Saving Time (DST) 2007 TechNet article. - Ben Winzenz, Nino Bilic, thanks also to Suresh Babu D33KViews0likes286CommentsExchange 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.28KViews0likes1Comment