Windows Mobile and Email data usage

A post on Windows Mobile data usage by  Jason Langridge's WebLog - MR Mobile!

Exchange 2003 (Pre-Service Pack 2)

From working with customers and looking at their data usage the average device used:

Smartphone - 4MB

Pocket PC Phone - 6MB

Pocket PC Phone was higher because most users tended to download more attachments. 

These numbers aren't too scary as you can get a very cheap data plan for that kind of data usage.  The highest I've ever hit on my device was 30MB when I was doing lots of demos of streaming media.

These numbers were all without any form of compression!

Exchange 2003 with Service Pack 2 and Windows Mobile 5

In SP2 we've added data compresssion to the Activesync solution which results in about 50-60% compression of email and 30-40% of compression for other items such as calendar, contacts and tasks.  Overall the compression rate is about 40-50% in my personal experience. 

Application Layer Firewall protection for Exchange Server 2003 with ISA Server 2004

Microsoft has released an upgraded ISA doc on configuring ISA2004 or Exchange.  Check it out....

http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/firewall-exchange2003.mspx

There is even a downloadable guide available.

Tips for disaster recovery readiness

Matthew Byrd has posted this article which describes what we all believe to be best practices for enterprise Exchange Design criteria.  Looks like our design work is right on track...

I have the pleasure of working for the Exchange Critical Situation team in North Carolina, so quite a few Disaster Recovery cases end up on my phone line.  The number one reason they end up there is that the company just has not planned for a failure.  We all assume that nothing is going to happen to us; (I am the same way, I live in hurricane country and yet I don’t have a hurricane kit or plan) but with Email and thus Exchange being mission critical to most businesses running it today, it is not an assumption any reasonable IT administrator can afford to make.

 

With that in mind I would like to share some basic things that everyone who is running Exchange needs to do in order to be prepared.  While a lot of this is not "brand new" knowledge, it does address many of the things that I see go wrong in the cases that I work on. DR Happens - Will you be ready?

 

Service Level Agreement

 

Here the common scenario we run into is that people have not thought about what is important if the Exchange server has a failure.  I will be on the phone working with a customer and we determine they need to do a restore from backup.  At this point (especially with 2003) there are a few ways we can go about doing that.  What is important to your company will help to determine the best way to do the restore. 

 

Not having this information decided in advance leads to long conversations with management to get the decisions made.  This can drastically slow down the pace of recovery.  In some rare cases I have ended up spending more time talking about what we could do then we spent actually doing it.

 

What you need to have decided ahead of time are a few simple questions:

 

1) Which one is more important to my users: Restoration of Mail Flow or Recovery of Historical Data?

2) How long can we afford to be down with out any Mail Flow?

3) How long can we afford to be down with no Historical Data Recovered?

4) If Historical Data is our top priority at what point does Mail Flow become more important and vice versa?

 

These four questions will help to define your options and what you can and cannot do in order to restore Exchange to the functional level that you desire in the minimal amount of time.  Having these decided in general is the first step to having a smooth disaster recovery.

 

Database Size

 

This is another common situation that I run into.  We are doing a restore from tape of a 120 Gb storage group and suddenly it is realized that the restore is going to take another 18 hours to finish and it is 11pm right now.  So it is going to cut into the business day and that can’t be allowed to happen.  Now we end up in a panic situation where people are willing to try any crazy scheme they can think of to get it back up before the morning.

 

This situation almost always comes about because people plan their database size based on their disk size and not the limitations of their Backup and Restore plan.  Database size should be determined almost solely by your SLA and your backup and restore speed.  This will ensure that when something goes wrong you will be able to get everything back up and running in a predictable and timely manner.

 

So what you need to do with database size is work it backwards.  Determined how long you can be without Historical Data.  Then determine how fast you can restore from tape.  Use those two numbers with some padding for troubleshooting when the failure is discovered and some padding for log file replay after the restore is done to determine how large your databases can be.

 

You also need to figure out if that number will hold when you have to restore a whole storage group of 5 databases or what if you have to restore a whole server of 20 databases?  In most cases you will probably want an SLA for each of those three situations. Since it clearly will take more time to restore 5 or 20 databases then it will to restore one.

 

Practice

 

Now let us say that you have been diligent and you have your SLA written out and you have your Databases at a reasonable size; you are all prepared right?  Wrong.  When it is time to do a disaster recovery mistakes are measured in hours.  Checking the wrong box on your backup software can cost you your entire SLA window.  Plus you don’t want to spend 30 minutes reading the directions for your Backup Software, or calling your backup vendor to figure out how to get the restore off of tape while you are offline.  You need to already be at least basically familiar with the restore process.

 

What you need to do is practice as if your Exchange server had failed.  We call this process running a Fire Drill.  You should run an Exchange Fire Drill at least once a Quarter to keep everyone up to date on how the restore process works and how to perform it.

 

To run a Fire Drill you should setup a server (beefy workstation) with sufficient drive space to accommodate the Exchange database from at least one of your servers.  You would then set it up on its own network with its own Domain Controller (if you are not testing full server restore then this can be a new domain).  Install Exchange to the server and your backup software and make sure you can get access to the data on tape.

 

Now you are ready to go.  Come in the next morning and declare “The Exchange server/Storage Group/Database (which ever you want to practice) just went down.  We need to get it back up and running we have “X” hours to do so.”  That X hours should be the time from your SLA that you have laid out before hand.  Also make sure that you have management involvement so that you can concentrate on doing the restore just as if the Exchange server was actually down.

 

Write a Cheat Sheet

 

Now you have gone thru the process of doing a Fire Drill and you learned what worked and what didn’t.  You have figured out all of the little check boxes and the fact that you have to keep the intern away from the tape drive power button.  Take all of the knowledge and the make yourself up a cheat sheet for next time.

 

This cheat sheet should contain an outline of the steps and processes that you need to go thru in order to do your planned restore.  It should include reminders of the little steps that you found are easy to miss.  If possible you should also include screen shots of all of the settings you need to have to do the restore on your backup software.  This cheat sheet will basically become your Restore Bible when it comes time for the real thing.

 

Practice some more

 

Last but not least you need to bring that cheat sheet out on a regular basis and practice with it.  Make sure your organization is doing an Exchange Fire Drill at least once a quarter.  Make sure that not just the Exchange guy is there for that, he should have a backup, in case he is on vacation, which can use the cheat sheet if necessary.  After each of these practice sessions go back over the cheat sheet and make sure nothing needs to be updated.

 

If you do these basic simple things you will be more prepared for when an Exchange Disaster does happen.  This should ensure that your disaster recovery goes smoothly with the minimum amount of down time.  With Disaster Recovery mistakes are measured in hours so it pays to be prepared.

 

References:

 

Exchange Server 2003 Disaster Recovery Operations Guide

http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/disrecopgde.mspx

 

Worksheet: Disaster Recovery Preparation for Exchange Server 2003

http://www.microsoft.com/technet/prodtechnol/exchange/2003/drchecklist.mspx

 

Preview: Exchange Server 2003 Disaster Recovery Planning Guide

http://www.microsoft.com/downloads/details.aspx?FamilyId=784BBEA2-28DD-409A-8368-F9914E993B28&displaylang=en

 

More details on Standard DB limit size increase in Exchange 2003 SP2

This article was posted a few days ago on You Had Me At EHLO...

As we mentioned before here, Exchange 2003 SP2 brings us increased database size limits for Exchange 2003 Standard servers with SP2 installed. There is more here than meets the eye, however, and I wanted to cover what the changes are exactly and how to configure this new functionality.

 

I should note here that the changes to new database size limit functionality have to be done through Windows Registry and there is no UI in ESM at this time. Please be careful! Those registry keys are read during database (not service) startup and when each limit check task is run.

 

Additionally, registry parameters have to be set for each database targeted for size limit modification. The registry entries should be located under each database entry in the local server registry (please note that by default, registry entries mentioned below are NOT present; by creating them, you are overriding the “default” value set in code).  Accordingly, the registry keys must manually be re-set if the server has to be rebuilt using the /disasterecovery setup switch.

 

All registry settings discussed here would be created in the following registry location (example):

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\<SERVER NAME>\Private-013e2e46-2cd7-4a8e-bfec-0e4652b94b00

 

The GUID above matches the value of the objectGUID attribute on the database’s Active Directory object.

 

Configurable Database Size Limit

 

Prior to Exchange 2003 SP2, there was no method to configure database size limits.  Exchange 2003 SP2 introduces a new feature that allows administrators to configure database size limits.  For Standard Edition, the default configured database size limit will be 18GB.  This is in contrast to the pre-SP2 hard coded limit of 16GB.   This size limit can be modified as shown later in this post.  Exchange 2003 SP2 increases the Standard Edition’s licensed database size limit from 16GB to 75GB.

 

The configurable database size limit for each database is available in both Standard and Enterprise editions. This feature enables an Administrator to set a protective database size limit in order to prevent unintentional database size growth. This limit is configurable up to the licensed database size limit (more details on this to follow).

 

Notable changes for Exchange 2003 SP2 size limits:

 

- Size check done against the database now uses logical database size.  Empty space in the database will not count against the configured database size limit, therefore no offline defrag will be required for recovery after running out of licensed database size.

 

- Limit checks, done at regular intervals, are now controlled by the store process instead of JET. The default time interval for this is 24 hours and is configurable via the registry (see below for details).

 

The following registry value controls the Configurable Database Size Limit:

 

Data Type	Name	Value	Default (in GB)
REG_DWORD	Database Size Limit in GB	Standard: 1-75 Enterprise: 1-8000	Standard: 18 Enterprise: 8000 (Unlimited)

 

Note: Some of you might ask – “Why 18GB as the default configurable limit, how did you get to 18GB?” We thought of customers that have possibly provisioned their storage with original 16GB limit in mind. Seeing that the default configurable limit is 18GB and the default warning buffer is 10%, that means that by default, 18GB – 10% (roughly 2GB) = there are warnings that start around 16GB. If the new default with Exchange 2003 SP2 install was 30GB for example, it is possible that some customers with disks provisioned for 16GB would run out of the hard drive space without any warnings.

 

Licensed Database Size Limit

 

Pre SP2, Exchange 2003 Standard Edition is limited to a single Storage Group with a single private and a single MAPI TLH public database. Each database in turn is limited to 16GB in total physical size. 16GB is considered too low of a limit to serve the current needs of Standard Edition customers.  As defined earlier, SP2 increases the licensed database size limit for Exchange 2003 Standard Edition from 16GB to 75GB; the default configured database size limit will be 18GB.  This is in contrast to the pre-SP2 hard coded limit of 16GB.

 

Exchange 2003 Version	Licensed Limit	Default Configured Limit	Notes
Standard Pre-SP2	16GB	Not Applicable
Standard SP2	75GB	18GB
Enterprise Pre-SP2	8000GB (unlimited)	Not Applicable
Enterprise SP2	8000GB (unlimited)	8000GB	Jet hardcoded limit is 8192GB = 8TB

 

Database Size Buffer Warning

 

 

By default, Exchange 2003 SP2 logs events when the database has grown to within 10% of the configured database size limit.  This threshold is configurable.  The smallest buffer is 1% of the configured size limit.

 

The following registry value controls the Database Size Buffer Warning:

 

Data Type	Name	Value	Default
REG_DWORD	Database Size Buffer in Percentage	1 - 100	10%

 

Timing of the Database Size Check

 

The database size check happens at 5am, every 24 hours by default.  This time can be changed via the following registry modifications.

 

If modified, next task is scheduled at the new Offset hour. Checks at Database Size Check Interval are skipped until new start time.

 

First database size check will not take the database offline if the size limit has been exceeded.  This also ensures at least 24 hour uptime after the limit is exceeded for default settings.

 

Data Type	Name	Valid Values	Default	Description
REG_DWORD	Database Size Check Start Time in Hours From Midnight	1 - 24	5 AM	Determines the hour the first Database Size check will take place after a database is mounted.

 

How It All Works together

 

At database mount, the store process will compare the physical database size against the “Configured Database Size Limit”.  Only if the physical size is within, or exceeds, the configured “Database Size Warning Buffer” then store will do a logical calculation of the database size. If it is below this warning buffer then there’s no need to calculate the free space because the logical size will never exceed the physical size.  In most cases the physical size is less than the warning threshold, so the size check should take under a millisecond to complete. If the free space calculation must be performed, then that may require a few seconds to parse through the database to generate the logical size calculation.

 

If the “Database Size Warning Buffer” is reached, or exceeded, then an error event will be logged in the Application event log. To get a better understanding of this concept see the following visual representation of limits & warning thresholds:

 

 

 

Behavior when the Configured Database Size Limit or Licensed Database Size Limit are reached

 

With Exchange 2003 SP2 (or later) the server will do the following when the Configurable (or default configured) Database Size Limit is reached:

 

- If the first check after a database mount finds the database size above the limit, the database will not be taken offline but an error event (ID 9689) will be logged in the Application event log.

 

- If it is the second check, an error event will be logged in the Application event log AND the database will be taken offline.

 

After the administrator re-mounts the database they will have 24 hours (or until the next database size check or 5AM (default) to take corrective actions.

 

 

Hope this was useful!

 

- Ethan McConnell, Michael Palermiti

 

E12 Developer Roadmap

In Exchange 12 (“E12”), we have focused our public API story on:

• Web Services for accessing information stored on the server
• Managed Agents for processing mail flowing through the server
• Windows Scripting Shell (Monad) “cmdlets” for managing the server itself

 

The Sep 15 PDC presentation, Future Directions - Building Custom Applications for Exchange 12 APIs, provides a great overview of these great new developer interfaces.  Our new Web Services will offer remotely-accessible Outlook-compatible business logic for all PIM types. Our new Managed Agent APIs for processing mail flow provide full access to either the raw MIME or message parts Outlook renders. Our new Monad scripting experience delivers the power and ease-of-use that our customers deserve. All of these new API’s have been designed with Visual Studio development in mind.

 

We use these API’s ourselves to build layers of the E12 product (i.e. Outlook “12” calls the Web Services, E12 anti-spam is completely implemented as Managed Agents, and our new admin GUI is entirely coded to the new cmdlets). This first-hand experience with the new API’s gives me confidence that you’ll find it much easier when you write applications which interface with E12.

 

The introduction of the new web services has freed us to “de-emphasize” three of the APIs introduced in previous generations of Exchange. These de-emphasized API’s will be fully supported in E12 (i.e. existing applications will work unchanged), and will be supported for 10 years after E12 releases, based on our standard Microsoft Support Lifecycle. These APIs may not be in future releases of Exchange beyond E12. All new applications should be written using the new Exchange Web Services. The 3 “de-emphasized” APIs are:

• CDOEx (aka CDO 3.0)
• WebDAV
• ExOLEDB

 

The architectural improvements in E12 mean that some APIs can no longer be supported at all. Applications that use these APIs will not function correctly against E12:

 

API	Will need to be replaced by
ExWin32 (aka M: or IFS)	Web Services
EDK Gateway	Managed Agents
Transport Event Sinks	Managed Agents
CDOExM	Monad “cmdlets”
WMI	Monad “cmdlets”
CDOWF	Windows Workflow Foundation
Web Forms	ASP.net

 

For each of the transitions, we plan to provide great guidance and samples within the E12 SDK. I look forward to your feedback on these new APIs, and our SDK support for the transition.

 

Thanks,

 

Terry Myerson
General Manager, Exchange Server

 

Microsoft Knowledge Base article to help search the Knowledge Base!!

The Microsoft Knowledge Base has more than 150,000 articles. These articles were created by thousands of support professionals who have resolved issues for our customers. The Microsoft Knowledge Base is regularly updated, expanded, and refined to help to make sure that you have access to the very latest information.

Using keywords and query words in Knowledge Base articles may help you find the content that you are looking for more quickly. This article lists some of the most frequently used keywords and query words in the Microsoft Knowledge Base.

Continue At Source

News Source: support.microsoft.com

Outlook Cmd Line Switches

I have known of some of the command line switches that Outlook 2003 supports for some time, but didn't have the full list.  While troubleshooting an issue, I found this website which lists all known Outlook 2003 switches (as of SP1). 

Using Command lines

To use switches, at the Start menu, Run command type:

Outlook /switch

Occasionally you'll need to use the full path to Outlook, so the command line looks like:

"C:\Program Files\Microsoft Office\Office11\Outlook.exe " /switch

Note:  Paths that include spaces between words must be enclosed in quotation marks (").
You'll need the full path if you create desktop shortcuts.

Switches

/a 

Creates an item with the specified file as an attachment.

Usage:

Outlook /a "C:\My Documents\labels.doc"

If no item type is specified, IPM.Note form is assumed. This switch cannot be used with message classes that aren't based on Outlook.

/altvba otmfilename

Opens the VBA program specified in otmfilename, rather than %appdata%\Microsoft\Outlook\VbaProject.OTM. Use this switch when you need to run macros not in your VBAProject file.

/autorun macroname

Opens Outlook and immediately runs the macro specified in macroname.

/c messageclass

Creates a new item of the specified message class, works for any valid MAPI form.

Examples:

• /c ipm.activity creates a Journal entry
• /c ipm.appointment creates an appointment
• /c ipm.contact creates a contact
• /c ipm.note creates an e-mail message
• /c ipm.stickynote creates a note
• /c ipm.task creates a task

/checkclient

Prompts for the default manager of e-mail, news, and contacts.

/cleanclientrules

Starts Outlook and deletes client-based rules. Used by non-Exchange account users.

/cleandmrecords

Deletes the logging records saved when a manager or a delegate declines a meeting. Used by Exchange Server accounts.

/cleanfinders

Removes Search Folders from the Microsoft Exchange server store.

/cleanfreebusy

Clears and regenerates free/busy information. This switch can only be used when you are able to connect to your Microsoft Exchange server.

/cleanprofile

Removes invalid profile keys and recreates default registry keys where applicable.

/cleanpst

Launches Outlook with a clean Personal Folders file (.pst) 

/cleanreminders

Clears and regenerates reminders.

/cleanrules

Starts Outlook and deletes client- and server-based rules.

/cleanschedplus

Deletes all Schedule+ data (free/busy, permissions, and .cal file) from the server and enables the free/busy information from the Outlook Calendar to be used and viewed by all Schedule+ 1.0 users.

/cleanserverrules

Starts Outlook and deletes server-based rules. Used only with Exchange server accounts.

/cleansniff

Deletes duplicate reminder messages.

/cleansubscriptions

Deletes the subscription messages and properties for subscription features. Used with SharePoint alerts.

/cleanviews

Restores default views. Use with care as all custom views you created are lost.

/designer

Starts Outlook without figuring out if Outlook should be the default client in the first run.

/embedding

Opens the specified message file (.msg) as an OLE embedding. Also used without command-line parameters for standard OLE co-create.

/explorer

Opens the new window in "explorer" mode (link bar on).

/f msgfilename

Opens the specified message file (.msg) or Microsoft Office saved search (.oss).

/firstrun

Starts Outlook as if it were run for the first time.

/folder

Opens a new window in "folder" mode (Navigation Pane off).

/hol holfilename

Opens the specified .hol file.

/ical icsfilename

Opens the specified .ics file.

/importprf prffilename

Launches Outlook and opens/imports the defined MAPI profile (*.prf). If Outlook is already open, queues the profile to be imported on the next clean launch.

/l olkfilename

Opens the specified .olk file.

/launchtraininghelp assetid

Opens a Help window with the Help topic specified in assetid.

/m emailname

Provides a way for the user to add an e-mail name to the item. Use either the full address or let alias resolve. Only works in conjunction with the /c command-line parameter.

Usage:

Outlook.exe /c ipm.note /m test@hrizns.com

Outlook.exe /c ipm.note /m garyc

/nocustomize

Starts Outlook without loading outcmd.dat (customized toolbars). With older versions of Outlook the *.fav file doesn't load.

/noextensions

Starts Outlook with extensions turned off, but listed in the Add-In Manager.

/nopollmail

Starts Outlook without checking mail at startup.

/nopreview

Starts Outlook with the Reading Pane off and removes the option from the View menu.

/p msgfilename

Prints the specified message (.msg). Does not work with HTML.

/profile profilename

Loads the specified profile. If your profile name contains a space, enclose the profile name in quotation marks.

/profiles

Opens the Choose Profile dialog box regardless of the Options setting on the Tools menu.

/recycle

Starts Outlook using an existing Outlook window, if one exists. Can be used in combination with /explorer or /folder. The Outlook shortcut in the Quick Launch bar uses the /recycle switch.

/resetfoldernames

Resets default folder names (such as Inbox or Sent Items) to default names in the current Office user interface language.

For example, if you first connect to your mailbox Outlook using a Russian user interface, the Russian default folder names cannot be renamed. To change the default folder names to another language such as Japanese or English, you can use this switch to reset the default folder names after changing the user interface language or installing a different language version of Outlook.

/resetfolders

Restores missing folders for the default delivery location.

/resetnavpane

Clears and regenerates the Navigation Pane for the current profile. Removes all Shortcuts and Favorite Folders. Has the same effect as deleting profilename.xml in your user directory.

/rpcdiag

Opens Outlook and displays the remote procedure call (RPC) connection status dialog.

/s filename

Loads the specified shortcuts file (.fav). Use to load *.fav files created in older versions of Outlook.

/safe

Starts Outlook without extensions, Reading Pane, or toolbar customization.

/safe:1

Starts Outlook with the Reading Pane off. New to Outlook 2003.

/safe:2

Starts Outlook without checking mail at startup. New to Outlook 2003.

/safe:3

Starts Outlook with extensions turned off, but listed in the Add-In Manager.

/safe:4

Starts Outlook without loading Outcmd.dat (customized toolbars) and *.fav file.

/select foldername

Starts Outlook and opens the specified folder in a new window.

Usage:

"C:\Program Files\Microsoft Office\Office11\Outlook.exe" /select outlook:calendar

outlook /select "outlook:Inbox\Old Messages"

/sniff

Starts Outlook and forces a detection of new meeting requests in the Inbox, and then adds them to the calendar.

/t oftfilename

Opens the specified .oft file.

/v vcffilename

Opens the specified .vcf file.

/vcal vcsfilename

Opens the specified .vcs file.

/x xnkfilename

Opens the specified .xnk file.

 

Setting the cookie authentication time-out in OWA 2003

 

Setting the cookie authentication time-out

For your Outlook Web Access logon page, you can give users two types of security options for authentication. Depending on their requirements, users can select either of these security options on the Outlook Web Access logon page:

Public or shared computer - Inform your users to select this option when they access Outlook Web Access from a computer that does not use the security settings for your organization. For example, an Internet kiosk computer does not use the security settings for your organization. The Public or shared computer option is the default option and provides a short default time-out option of 15 minutes.

Private computer - Inform your users to select this option when they are the sole operator of the computer and the computer uses the security settings for your organization. This option permits a much longer period of inactivity before automatically ending the session. Its internal default value is 24 hours. The Private computer option is intended to benefit Outlook Web Access users who use personal computers in their office or in their home.

Additionally, when Outlook Web Access clients log on by using forms-based authentication, they may also choose between the following two types of Outlook Web Access client versions:

	Premium - This is the default version. It provides all Outlook Web Access features.     Note: The Outlook Web Access premium client has special code so that typing in a message body is considered as activity.
	Basic - This version provides faster performance but fewer features than the premium client. Use this version if you are on a slow connection.

In Exchange 2003, Outlook Web Access user credentials are stored in a cookie. When the user logs off from Outlook Web Access, the cookie is cleared and it is no longer valid for authentication. Additionally, by default, if your user is using a public computer and selects the Public or shared computer option on the Outlook Web Access logon screen, the cookie on this computer expires automatically after 15 minutes of user inactivity.

The automatic time-out is valuable because it helps protect a user's account from unauthorized access. However, although the automatic time-out greatly reduces the risk of unauthorized access, it does not completely eliminate the risk that an unauthorized user could access an Outlook Web Access account if a session is left running on a public computer. Therefore, make sure that you educate users about precautions to take to avoid risks.

To match the security requirements of the organization, an administrator can configure the inactivity time-out values on the Exchange front-end server. Exchange 2003 uses the following information to determine user activity:

	Interaction between the client and the server is considered as activity. For example, if a user opens, sends, or saves an item, switches folders or modules, or refreshes the view or the Web browser window, this is considered as activity.
	If a user enters text in Outlook Web Access items, it is not considered as activity. For example, if a user types in appointments, meeting requests, posts, contacts, tasks, or other items, this is not considered as activity.

To configure the time-out value, you must first enable forms-based authentication and then modify the registry settings on the server.

To set the Outlook Web Access forms-based authentication public computer cookie time-out value, follow these steps.
Warning If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.

1.	On the Exchange front-end server, log on by using the Exchange administrator account, and then start Registry Editor.
2.	Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA
3.	On the Edit menu, point to New, and then click DWORD Value.
4.	Type PublicClientTimeout for the name of the DWORD, and then press ENTER.
5.	Right-click the PublicClientTimeout DWORD value, and then click Modify.
6.	Under Base, click Decimal.
7.	In the Value data box, type a value that represents the number of minutes for the time-out. This number must be between 1 and 43200. (43200 minutes are equal to 30 days.) If you do not set a value, a value of 15 is assumed. Note The maximum possible value is 43200 for 30 days.
8.	Click OK. Important You must restart IIS for the changes to take effect. Also, if you set the TrustedClientTimeout value to a value that is lower than PublicClientTimeout, the TrustedClientTimeout value defaults to be equal to the PublicClientTimeout value. Likewise, if you set the PublicClientTimeout value to a value that is greater than the TrustedClientTimeout value, the TrustedClientTimeout value defaults to be equal to the PublicClientTimeout value.

To set the Outlook Web Access forms-based authentication trusted computer cookie time-out value:

1.	On the Exchange front-end server, log on by using the Exchange administrator account, and then start Registry Editor.
2.	Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA
3.	On the Edit menu, point to New, and then click DWORD Value.
4.	Type TrustedClientTimeout for the name of the DWORD, and then press ENTER.
5.	Right-click the TrustedClientTimeout DWORD value, and then click Modify.
6.	Under Base, click Decimal.
7.	In the Value data box, type a value that represents the number of minutes for the time-out. This number must be between 1 and 43200. (43200 minutes are equal to 30 days.) If you do not set a value, a value of 1440 is assumed. Note The maximum possible value is 43200 for 30 days.
8.	Click OK.
9.	Open a command prompt, type net stop w3svc, and then press ENTER.
10.	After the services stop, type net start w3svc, and then press ENTER.

 

In addition to idle timeouts, you can also specify a timeout value for the Forms Based Authentication cookie itself. To do this, add the following registry entry to the OWA server.

 

Location: HKLM\System\CurrentControlSet\Services\MSExchangeWeb\OWA
Value: KeyInterval
Type: REG_DWORD
Value Data: Timeout value (in minutes)