Exchange Queue & AOWA Timeouts, Cmdlet Troubleshooting, and More
KC Lemson and Nino Bilic
Q We recently migrated from Exchange Server 2003 to Exchange Server 2007. We are receiving complaints that Outlook® Web Access (OWA) is timing out for Restricted Users who have selected the "This is a private computer" option when logging into OWA 2007. What is the appropriate Exchange Management Shell command to verify the timeout for private computers?
A Let’s back up a second. First I’ll explain why there’s a separate selection for a private computer versus a public computer (see Figure 1) and I’ll show you how these options behave differently. The intention is to give the user a way to tell Exchange what level of security is necessary—whether you’re logging on to OWA using a public kiosk at an airport, for example, or logging on using your home computer. The Exchange administrator can choose to treat those session types differently. For instance, the administrator can make authenticated sessions time out faster on public machines (in, say, a matter of minutes) than on private machines (up to three days maximum). The administrator can also configure other settings differently depending on the user’s selection. For example, the administrator might set access to SharePoint® document libraries and Windows® file shares to be allowed only for the private logon. Of course, this relies on the user specifying the right option. If admins don’t trust users to make the right decision, they can give each option the same timeout values and other configuration options.
Figure 1** The public and private computer session types allow for different timeout settings and other configuration options **(Click the image for a larger view)
The option in question is one we carried over from Exchange 2003, when forms-based authentication was first introduced to OWA. (Historical note: the first implementation of forms-based authentication was designed in part by a brilliant program manager. I won’t reveal her identity, but I will tell you that she later found fame and fortune writing a bimonthly column for TechNet Magazine.)
The setting is actually stored in the registry, but since Windows PowerShell™ has an interface to update the registry, you can configure this setting using the Exchange Management Shell. The following example sets the timeout to 1440 minutes, or one day, when users choose the private computer option during logon:
set-ItemProperty ‘HKLM:\SYSTEM\CurrentControlSet\Services\
MSExchangeOWA’ -name TrustedClientTimeout
-value 1440 -type dword
Of course, since the setting is in the registry, you can update the key yourself using regedit, should you so choose:
#include <standard disclaimer about mucking
with the registry.h>
#include <musing from author about when as a
company we will ever be able to stop making
that standard disclaimer about mucking with
the registry.h>
Either way, you’ll need to restart IIS to ensure that OWA picks up the new setting. You should be able to do this by selecting Start | Run and then running iisreset /noforce.
Q We encourage everyone at work who uses the full MAPI Outlook clients to archive all less-than-urgently needed items into personal folders (.pst) files. However, the archived items are then not available when users log into Outlook Web Access from home. How can we make these .pst files available through the OWA interface?
A I’m sorry to tell you that OWA does not support access to .pst files. OWA was built from the ground up to be an online-only client. We have done a lot of work to make sure we don’t leave any traces of personal data on the local machine—this includes features like the secure logoff mechanism first delivered in Exchange 2003 and the WebReady Document Viewing in Exchange 2007, which ensures that cached copies of attachments aren’t left on the hard drive. So accessing .pst files from OWA does not fit in with our goal of making it a simple-to-deploy, online-only client.
That said, .pst usage in general is an interesting scenario that we’d like to discuss. We met with a customer last fall who had users with mailbox quotas of about 200MB, and nearly every user had at least one, if not more, .pst files. Because this organization had a policy that enabled wiping and replacing user machines with minimal effort, all users were required to store their .pst files on a network share. That network share was, in turn, backed up by a central system.
First, there are known problems when accessing .pst files from network shares. Just as OWA was designed from the beginning to be online-only, .pst files were originally intended to be stored locally. No matter how excellent your network is, it’s subject to latency and other problems that can make remote storage of data (that also needs to be accessed by users at the same time) problematic.
Second, this organization had what we would call a smallish mailbox quota (we, admittedly, live in the lap of luxury with a corporate mailbox of around 2GB) because it didn’t want to have all of that data in Exchange—because it would then be responsible for backing up all that data. Yet, with users storing the data in .pst files on a network share that was backed up, the administrators weren’t really saving themselves any work. In fact, it was probably creating more work due to a variety of factors, such as: no single-instance storage across multiple .pst files; helpdesk costs related to problems with .pst files (such as forgotten passwords and general network flakiness); difficulty cleaning up messages in .pst files after a virus attack; difficulty discovering messages in .pst files when a legal matter arises; overhead of maintaining a different backup system; and so on.
So we urge you to consider all of the costs around your configuration decisions. You might find that the costs add up and another configuration may ultimately make a better choice.
Q I’m having a problem with an Exchange Management Shell command. It’s just not working. What’s wrong?
A We can’t answer that question, but we can tell you that in order to get the best help possible—wherever you may be looking—you should use the built-in cmdlet in Windows PowerShell called start-transcript to log the commands you’re trying and the results you get. This lets you then paste the exact details into an e-mail message, blog post, or question on a forum.
Open up an Exchange Management Shell session and type start-transcript, as in Figure 2. Exchange Management Shell will automatically start logging all future commands into a text file like the one in Figure 3 (don’t worry, the app will tell you the location of the text file). To stop logging, you simply type stop-transcript.
Figure 2** Use the start-transcript cmdlet to log the commands you use and their results **(Click the image for a larger view)
Figure 3** Windows PowerShell saves a transcript of the commands you use and stores it in a .txt file **(Click the image for a larger view)
Having the full list of commands you used and the results returned is an immense help to anyone troubleshooting your problem. But before sharing the log with anyone you don’t know or trust, make sure you review it for any confidential or sensitive data that may have been returned.
Q I see that the Exchange 2007 setup creates a new Organization Unit (OU) in the root domain. It is called Microsoft Exchange Security Groups and it holds five new Exchange 2007 security groups. Can we move those groups to a different OU? How about to a different domain?
A This question refers to five universal security groups (USGs) that are created in the root domain during the preparation stage of Active Directory. The groups in question are:
- Exchange Organization Administrators
- Exchange Recipient Administrators
- Exchange View-Only Administrators
- Exchange Servers
- ExchangeLegacyInterop
In the days of Exchange 2000 and Exchange 2003, the ability to move the default security groups around (Exchange Domain Servers and Exchange Enterprise Servers) was limited. OK, a better way to say this is that you could move them, but you would break things in the process. (Check out support.microsoft.com/kb/260914 for more details on this problem.) So this was very limited indeed.
In Exchange 2007, things are different. The default five groups can be moved. You can move them to a different OU within the same domain or to a different domain altogether.
In case you ever "lose" those five groups and don’t know where you moved them to—meaning which OU or domain—you can always check the value of the otherWellKnownObjects attribute on the following container:
CN=MicrosoftExchange,CN=Services,
CN=Configuration,DC=<DomainName>,DC=com
As groups get moved around, their location is updated on this attribute, giving you a way to always find out where the groups are. Neat!
Q I found a Global Security group called "Exchange Install Domain Servers" in my domain. What is it for?
A You are definitely keeping tabs on your Active Directory®. Indeed, there will be a group called Exchange Install Domain Servers in every domain that has Exchange 2007 servers installed. This group is created in the Microsoft Exchange System Objects (MESO) OU. If you examine this group, you will see that it is being made a member of the root domain’s Exchange Servers group, which is a Universal Security Group.
To put it succinctly, Exchange Install Domain Servers is a group used to work around possible long Active Directory replication cycles if you are running Exchange 2007 setup in one of your child domains. For example, say you have a root domain called Root, a child domain called Child, and a child domain of Child called Grandchild. (We know, the naming scheme is brilliant! Think you can guess what our passwords are?)
To start setting up Exchange 2007 in this org, you first have to extend the schema and prepare your Root domain. This creates the original five USGs we discussed in the previous answer.
Then, say you need to run setup in the Grandchild domain. In order to be able to start the Exchange 2007 services in the local domain, setup puts a computer account of the Exchange 2007 machine into the Exchange Servers group from the Root domain. But since you are now in the Grandchild domain, the membership of the Exchange Servers group might take a while to replicate.
Exchange Servers is a universal group and its membership replicates throughout the forest. Due to potential replication latency, it is possible that setup in the Grandchild domain could fail to start services, as permissions would not be replicated by the time setup was done. That is why when the first Exchange 2007 server is set up in a domain, it will create the Exchange Install Domain Servers group in the local domain.
The Exchange computer account will be placed as a member in that group as part of the setup. A membership in this group gives services enough permissions to start at the end of setup, even if the membership of the Exchange Servers group has not yet replicated from the Root domain. Note that local domain replication is usually faster than replication between domains.
Q The Exchange 2007 documentation tells me I should be running setup with the /PrepareLegacyExchangePermissions switch, even before I extend my schema for Exchange 2007. Why is that? (And could you have made the name of this switch any longer?)
A We’re glad to hear you are reading the documentation before running Setup. How do you like it?
The /PrepareLegacyExchangePermissions (or /pl for short) is a switch that, in so many words, gives Exchange 2000 and Exchange 2003 Recipient Update Services (RUSes) permissions to write to the Exchange Information and Personal Information property sets. During the Exchange 2007 schema extension process, several attributes (such as Proxy Addresses) are moved from the Active Directory Public Information property set into the Exchange Information property set. By default, Exchange 2000 and Exchange 2003 RUSes don’t have the rights to write to the Exchange Information property set. In real life, this means that if you run your Exchange 2007 schema extension first, you will break your Exchange 2000 and Exchange 2003 RUSes because they will be unable to stamp any new recipients! (If you want to read more about those property sets, please go to our blog at msexchangeteam.com.)
Therefore, it is very important that you run the /pl switch before the schema is extended for Exchange 2007. You should also make sure that this change replicates to all domains that have Exchange 2000 or Exchange 2003 recipients (so RUSes exist for those domains). If new domains are added to the forest at a later time and you need to put Exchange 2000 or Exchange 2003 RUSes into them, you should run /pl switch in those domains too.
On that note, when running a /pl switch for the first time, life will be much simpler if you run the switch with an account that has Enterprise Admin rights. Then, setup from root domain will identify which domains need to have /pl run on them and it will run the /pl switch on all of those domains. If you are not using an Enterprise Admin account, you will have to run a /pl switch using a Domain Admin for each domain individually. Fortunately, the Exchange 2007 documentation lays out all the permissions requirements.
And finally, you asked whether we could have made this switch any longer. Just try to say /PrepareLegacyExchangePermissions three times quickly:
PrepareLegacyExchangePermissions
PrepareLegacyExchangePermissions
PrepareLegacyExchangePermissions
We thought of making this /Prepare-LegacyExchangePermissionsWOWThisIsaReallyLongname, but then we opted for the shorter and friendlier /PrepareLegacyExchangePermissions.
OK, we just made that up. But you can always use the much shorter /pl. And that one is true—we swear!
KC Lemson is the User Experience Manager for Exchange Server. She spends her free time waiting for e-mail to arrive to tell her where she should invest her kids’ college funds.
Nino Bilic, a Technical Lead for Exchange Server, is busy keeping tabs on how many games of Halo he can get away with during a typical work day.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.