Shutdown Changes for Outlook 2010
Summary: As part of the goal to improve performance, Microsoft Office Outlook 2007 Service Pack 2 (SP2) and Microsoft Outlook 2010 include some significant changes to ensure that Outlook shuts down properly when the user attempts to close it. This article describes the changes to Outlook 2010.
Applies to: Office 2007 | Office 2010 | Outlook 2007 Service Pack 2 (SP2) | Outlook 2010
In this article
Background
Add-in Shutdown Changes in Outlook 2010
Best Practices for Add-in Shutdown for Developers
Best Practices for Add-in Shutdown for IT Administrators
Conclusion
Additional Resources
Published: November 2009 | Updated: May 2010
Provided by: Ryan Gregg, Microsoft Corporation
Contents
Background
Add-in Shutdown Changes in Outlook 2010
Best Practices for Add-in Shutdown for Developers
Best Practices for Add-in Shutdown for IT Administrators
Conclusion
Additional Resources
Background
Before Outlook 2007 SP2, Outlook often took much longer than expected to shut down on command. The goal in Outlook 2010 is to ensure that it shuts down quickly and consistently.
In Outlook 2007 SP2, Outlook prevented external COM add-ins from keeping Outlook running after the user closed Outlook (for more information, see Application Shutdown Changes in Outlook 2007 SP2). Outlook 2007 SP2 also prescribed a new design for MAPI providers to prevent data loss before Outlook exited. The disadvantage was that all MAPI providers had to opt in to the design and support the new behavior.
In the Outlook 2010 Technical Preview release, the design was modified in such a way that MAPI providers implement the IMAPIProviderShutdown : IUnknown interface to perform timely and necessary steps. Those steps prevent data loss that can result when the client disconnects external references before the client exits. The fast-shutdown mechanism is now the default for all MAPI providers except for those that explicitly opt out by returning MAPI_E_NO_SUPPORT to the IMAPIProviderShutdown::QueryFastShutdown method. Even if a MAPI provider does not implement the IMAPIProviderShutdown interface, Outlook 2010 still uses the fast-shutdown mechanism. For more information about the MAPI client and the provider fast-shutdown mechanism, see Client Shutdown in MAPI.
These changes for external COM add-ins and MAPI providers have done a lot to ensure that Outlook always shuts down, and does so quickly, as the user intends. However, some Outlook in-process add-ins carry out processor-intensive operations and network I/O during shutdown events. Because of their impact on the perceived performance of Outlook, Outlook 2010 includes a fast-shutdown model for in-process add-ins that further improves the shutdown behavior in Outlook.
Add-in Shutdown Changes in Outlook 2010
Starting in Outlook 2010, Outlook, by default, does not signal add-ins that it is shutting down. Specifically, Outlook no longer calls the OnBeginShutdown and OnDisconnection methods of the IDTExtensibility2 interface during fast shutdown. Similarly, an Outlook add-in written with Microsoft Visual Studio Tools for Office no longer calls the ThisAddin_Shutdown method when Outlook is shutting down.
The impact of the changes on an add-in depends on what the add-in does during these events. Most add-ins use these events to release references to Outlook COM objects and clear memory that was allocated during the session. In these cases, the impact on the add-ins is minimal; Outlook releases the remaining COM object references and shuts down, and Windows reclaims the memory when the Outlook process exits.
For some add-ins, the changes have more impact. If an add-in uses these events to commit data (for example, to store user settings or to report usage to a Web server), those activities will no longer take place. Depending on the scenario, this may or may not have a visible impact to users. To remedy the situation, the add-in developer can modify the add-in to be compatible with the changes, or an IT administrator can use group policy to restore the original behavior for a specific add-in.
Important
The OnBeginShutdown and OnDisconnection methods can still be called in other scenarios (for example, if the add-in is manually disconnected or if slow shutdown is enabled through group policy to revert to the behavior before Outlook 2007 SP2). Therefore, it is important that developers continue to implement these methods.
Why Change Now?
Outlook developers understand that this change has a significant impact, but made the decision after a careful analysis of abundant performance data.
For example, data from Outlook 2007 SP2 indicated that if the user had "misbehaving" add-ins installed, the average delay to shutdown was 13 seconds. Data from the Outlook 2010 Technical Preview showed an average delay of 15-20 seconds.
Further tests that were designed to show what add-ins did during their shutdown or disconnect events revealed that while a majority of add-ins perform simple tasks like releasing references, some add-ins make Web service calls or other long-running operations synchronously during these events.
The benefit of the change is that for the majority of add-ins and customers, Outlook will work significantly better than it has in the past when shutting down. The change improves the ability of Outlook to respond to the user’s intent and exit quickly so that the user can move on to the next task or to shut down the computer.
Best Practices for Add-in Shutdown for Developers
For add-in developers, the new shutdown can seem a little tricky at first. It is important that developers follow the best practices for add-in shutdown to ensure that end users continue to benefit from a fast and responsive Outlook shutdown experience.
Practice #1: Continue to release references in OnDisconnection
It is important that you continue to write code that includes OnDisconnection or ThisAddin_Shutdown to release any remaining COM references to Outlook objects. In Outlook 2003 and Outlook 2007 before SP2, these COM references could prevent Outlook from shutting down. In Outlook 2010, you should continue to implement these events to release references and allocated memory because there are scenarios in which administrators can revert to slow shutdown through group policy, or the user can manually disconnect your add-in through the COM Add-ins dialog box.
Practice #2: Detecting when Outlook is shutting down
To detect that Outlook is shutting down, you can use the Quit event of the Application object in the Outlook object model to receive a notification that the process is shutting down. Be sure that you respond quickly to the event and return control to Outlook as quickly as possible. Your add-ins should create no delay in Outlook shutdown that is perceptible to the user. Compare the time it takes for Outlook to shut down with only your add-in running, and the time it takes for Outlook to shut down without any add-ins running to identify any significant difference.
If your add-in has long-running operations to perform at shutdown, or has operations of indeterminate length to perform at shutdown, consider the following questions:
Does each operation need to happen when Outlook shuts down?
What happens if Outlook crashes and the code for those operations does not run?
Can the operation take place at an earlier time before shutdown (for example, committing the changes when the user makes the change instead of saving the operation for later)?
Can the operation take place on a background thread instead of synchronously during a quit event?
Note
You cannot make calls to the Outlook object model from a background thread, but you can use MAPI directly if you initialize MAPI properly in your add-in. For more information, see Starting a MAPI Session.
Explicitly, do not perform network I/O operations during any quit event. This includes saving data to a network share, writing data to an Outlook online-mode store, or calling Web services during Application.Quit, OnBeginShutdown, or OnDisconnection.
When you use the Application.Quit event, do not perform any release of Outlook COM objects or allocated memory in the Outlook process space. Outlook and Windows take care of that when your process exits.
Tip
During add-in compatibility testing, there was a sample internal Outlook add-in that reported usage information back to a Web service during the shutdown events. Instead of reporting the data directly to the Web service during shutdown, the developer modified the add-in to save and report the previous session usage information on a background thread when Outlook started the next time. That way, the data is still uploaded, and the operation never blocks Outlook—a very useful technique.
If your solution consists of another executable file, consider moving certain operations out of the add-in into the executable file. That way, the operations take place regardless of whether Outlook is running, and do not block the ability of Outlook to start up or shut down quickly.
Practice #3: Test shutdown by using both the fast and slow methods
As a developer, you should ensure that your add-in poses a negligible performance impact to Outlook users. At a minimum, test the impact that your add-in has on Outlook startup time, on common scenarios (for example, composing a new message, replying to a message, switching folders, and sending mail), and on Outlook shutdown. Specifically, test the shutdown times of Outlook under different Windows registry settings for the add-in to control how Outlook shuts down.
Best Practices for Add-in Shutdown for IT Administrators
For IT administrators, if you have internal add-ins or solutions that cannot be updated to support the new design, there are two ways to enable shutdown notifications to Outlook add-ins in Outlook 2010, and revert to the earlier shutdown behavior:
Selectively for individual add-ins (the preferred approach)
IT administrators can enable shutdown notifications to individual Outlook add-ins as part of the add-in deployment. Although you cannot do this through group policy, it is useful if you have backward-compatibility requirements for specific add-ins.
Globally for all add-ins
IT administrators can enable shutdown notifications globally for all add-ins through group policy. This is recommended for organizations with a large number of internal solutions or desktops that need to deploy this setting to ensure compatibility during a rollout of Outlook 2010.
Individual Add-in Setting
With this setting, Outlook selectively provides shutdown notifications to the specified add-in without notifying all add-ins. Configure this setting for each add-in through the add-in registration in the HKCU or the HKLM registry hives, by adding an additional value to the add-in registration. Type the following text as a single line.
HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\<ProgID>\[RequireShutdownNotification]=dword:0x1
Setting this value to 0x1 enables the add-in to receive blocked callbacks during Outlook shutdown. This has an impact on the performance of Outlook shutdown and should be evaluated as part of a deployment. This setting should be used only if an add-in has significant compatibility issues with the new shutdown mechanism. Setting the value to 0x0 uses the default behavior of Outlook 2010.
Global Setting
Use this setting to change the new shutdown mechanism to match that used by Outlook 2007. You can deploy the setting through group policy, either per user or per computer. Type the following text as a single line.
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\14.0\Outlook\Options\Shutdown\[AddinFastShutdownBehavior]=dword:0x1
Setting AddinFastShutdownBehavior to 0x1 enables shutdown notifications for all add-ins. Setting the value to 0x0 uses the default behavior of Outlook 2010.
These two settings provide administrators complete control over the effect that this new behavior has on custom solutions and add-ins that are used in the enterprise. It is important that organizations test any custom solutions using Outlook add-ins to ensure compatibility with this change.
Conclusion
Outlook 2010 provides a new mechanism for in-process Outlook add-ins to shut down without impacting the overall perceived shutdown behavior of Outlook. However, while Outlook no longer calls the OnBeginShutdown and OnDisconnection methods of the IDTExtensibility2 interface, add-ins should still implement these methods or ThisAddin_Shutdown to release references and allocated memory, because there are scenarios in which administrators might revert to slow shutdown through group policy, or the user might manually disconnect your add-in through the COM Add-ins dialog box. Add-in developers should proactively modify their add-ins to work with Outlook 2010, only perform tasks that absolutely must take place during shutdown, and evaluate the performance of their add-ins in various scenarios and under different Windows registry settings that control Outlook shutdown. In cases where there are add-ins that are already deployed in an enterprise and that IT administrators cannot upgrade to become compatible with this new shutdown mechanism, IT administrators can resort to a couple of new Windows registry settings to revert to the slow shutdown behavior.
Additional Resources
For more information, see the following resources: