Other Problems


Topic Last Modified: 2005-07-17

This section contains information about how to resolve problems that do not fit into the other categories in this section. These issues include the following:

  • Unable to access permissions on a public folder (Invalid Windows Handle Error)

  • One or more users could not be added to the folder access list

  • Mail messages to public folder were not delivered

  • Outlook Web Access cannot view a public folder after the tree has been renamed

  • Message "Operation Failed" when attempting to access a tree using Exchange System Manager

  • Exchange Server 5.5 servers see multiple public folder stores on an Exchange Server 2003 server

  • In a mixed Exchange Server 2003 and Exchange Server 5.5 environment, users cannot access a public folder using Outlook Web Access

  • Attachment exceeds storage limit on public folder

The most frequent cause of the Invalid Windows Handle Error in Microsoft Exchange 2000 Server is an administrator's use of the M:\ drive (the Exchange Installable File System) to modify permissions on a public folder. Servers running clean installations of Exchange Server 2003 do not have an M:\ drive, although it may still be accessible on upgraded servers that previously ran Exchange 2000 Server.

This error can also arise if you use the wrong dialog box in Exchange System Manager to modify client permissions on a public folder, although this is unlikely to occur. For more information about the correct way to modify permissions on a public folder, see "Special Considerations for Working with Client Permissions" in the Exchange Server 2003 Administration Guide.

The underlying cause of this error is that, if you use the Windows user interface to modify client permissions for a public folder, the permissions are stored in such a way that Exchange Server 2003 is no longer able to convert the permissions to their MAPI form. If this happens, you will no longer be able to use the dialog boxes in Outlook or Exchange System Manager to edit the permissions.

After you use this procedure, the affected public folders will have permissions for only the folder owner (an administrative account), Default users, and Anonymous users.

For detailed steps about how to reset permissions on public folders, see How to Reset Permissions on Public Folders.

Either Outlook users or administrators using Exchange System Manager could see this message when trying to grant users permissions to a folder in the Public Folders tree. When this error occurs, Default and Anonymous permissions on the affected folder do not work. Only users that were previously granted permissions to the folder are able to access it. However, if you try to use the Properties button to view the properties of one or more of those users in the folder's Client Permissions dialog box, you will get a MAPI error message. The affected users are the root of the permissions problem.

This permissions problem occurs when a user who does not have an Exchange mailbox creates or administers a folder in such a way that the user is granted explicit permissions to the folder. (This can happen using Exchange System Manager or the Exchange Installable File System.) The most likely cause is that someone used an account that has permissions to administer folders (for example, an account that belongs to the Enterprise Admins group), but no mailbox was ever created for that account.

To fix this problem, in the folder's Client Permissions dialog box, identify the user whose properties you cannot access. Remove the user from the folder's access control list, or go to the Active Directory Users and Computers snap-in and create a mailbox for that user.

If you have a mixed-mode Exchange organization, check that the public folder connection agreement has replicated the folder's directory objects correctly. Remember that you cannot send general purpose hierarchy folders from Exchange Server 2003 if the e-mail message travels by way of an Exchange Server 5.5 server.

In any Exchange organization, an e-mail message to a folder first needs to go to a public folder store that supports the correct public folder tree to find the replica list for the destination folder. It may be that the public folder store that was chosen has not received the updated replica list of the destination folder yet.

When you rename a public folder tree, you have to update all of the virtual directories that point to that tree. The changes will not finish propagating from Exchange Server 2003 to Internet Information Services (IIS) until after the public folder store has been remounted.

For detailed steps about how to update virtual directories and propagate changes after you rename a public folder tree, see How to Update Virtual Directories and Propagate Changes After You Rename a Public Folder Tree.

To access the public folder trees, Exchange System Manager uses an OLEDB service that depends on the World Wide Web Publishing Service (W3SVC). If you have problems accessing a tree using Exchange System Manager, check the following:

  • Check that World Wide Web Publishing Service is running on the Exchange Server 2003 server.

  • Check that the Microsoft Internet Explorer settings do not have a non-existent proxy server configured.

This problem can occur if a new configuration connection agreement (Config CA) replaces an existing Config CA. This replacement can occur, for instance, if servers running Site Replication Service (SRS) are removed from the organization incorrectly.

The problem starts when the new Config CA replicates the Active Directory object for a default public folder store from an Exchange Server 2003 server in an Exchange Server 2003 administration group to the Exchange Server 5.5 directory of an Exchange Server 5.5 server. The new Config CA does not see that the Exchange Server 2003 default public folder store's object already exists in the Exchange Server 5.5 directory because the object has the old Config CA's replication signature.

As a result of the replication cycle, a second default public folder store appears in the Exchange Server 5.5 directory for the Exchange Server 2003 server. Because the server's container already has an object called Microsoft Public MDB, the new object is named Microsoft Public MDB – 1. However, this name is too long for a public folder store object in Exchange Server 5.5, and, as a result, the replication engines on Exchange Server 5.5 servers will fail to start throughout the organization.

The following errors will be logged:

Error 0x3f0 occured while performing a site folder teardown check

Event 3079 MSExchangeIS Public

Unexpected replication thread error 0x3f0




The site folder teardown check referred to in the error message is performed each time an Exchange Server 5.5 server starts, to determine whether any sites have been removed, in which case the list of site folders (such as SCHEDULE + FREE BUSY) needs to be cleaned up. You can do this clean-up by comparing details about all of the site folders with details about all of the public folder stores in the organization.

Because the string Microsoft Public MDB – 1 is too long, the replication thread fails with an Out Of Memory error (0x3f0) when it tries to get site details of the store with that name. This failure in turn causes the replication engine to fail to start. The only way to fix this problem is to remove both the incorrect directory object and the original correct directory object for the Exchange Server 2003 public folder store from the Exchange Server 5.5 directory, and replicate the directory entry again.

Before you remove the Exchange Server 2003 default public folder store objects from the Exchange Server 5.5 directory and allow the correct object to replicate back, contact Microsoft Product Support Services to ensure that you do it correctly.

Microsoft Outlook Web Access users cannot access folders that exist only on Exchange Server 5.5 servers. Check your public folder connection agreements to make sure that the folders are being replicated to at least one Exchange Server 2003 server.

After you install Exchange Server 2003 (or Exchange 2000 Server Service Pack 1 (SP1) or later), when you use Microsoft Office Outlook Web Access to post a new item with an attachment that is larger than 1 megabyte (MB) to a public folder, you receive the following error message:

This item exceeds the maximum size defined for this folder and cannot be saved. Contact your administrator to have the folder limits increased.

Attachments that are smaller than 1 MB are not affected. This issue occurs even if no limits are set on the public folder store, and it only affects Outlook Web Access users. Outlook users are not affected.

This issue occurs because a system folder called OWAScratchPad{GUID} is created when a user adds an attachment to a public folder post. This system folder has a limit of 1,024 kilobytes (KB).

To work around this issue, use Exchange System Manager to either increase or remove the limit on the OWAScratchPad{GUID} folder.

On every Exchange 2003 server installation that does not have message size limits set, the maximum item size for public folder messages is set to 10240 kilobytes (KB). This setting also affects new public folder stores created using Exchange System Manager. For detailed steps about changing or removing the size limit for attachments in public folders see How to Change or Remove the Size Limit for Attachments in Public Folders.