Information in this document, including URL and other Internet Web site references, is subject to change without notice and is provided for informational purposes only. The entire risk of the use or results of the use of this document remains with the user, and Microsoft Corporation makes no warranties, either express or implied. Unless otherwise noted, the example companies, organizations, products, people and events depicted herein are fictitious and no association with any real company, organization, product, person or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
Copyright 2002 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Active Directory, ActiveSync, and Outlook are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries.
This document contains the following sections:About This Document
Important You should read both the release notes and the information in the Getting Started guide prior to deploying and running Microsoft® Exchange Server 2003. Important information necessary for successfully testing the beta release of Exchanage 2003 may not be covered in the release notes. The release notes cover known issues with the beta release. Other important information such as deployment steps is covered in the Getting Started guide.
New or updated Help content and core documentation is not yet available for Exchange Server 2003. For this beta, the following documents are available:
The release notes list known issues with the Exchange Server 2003 beta release.
The other document, "Microsoft Exchange Server 2003 Getting Started Guide," provides information on deploying Exchange Server 2003 as well as an overview of new features and how to use them. The Beta release of Exchange Server 2003 is only supported in a test environment.
For information about deploying and using Exchange Server 2003 Beta, including system requirements, prerequisites, and changes from Exchange 2000 Server to Exchange Server 2003, see the Getting Started guide.
This section explains the test environments you can use to deploy Exchange Server 2003 Beta.
Pre-release (beta) versions of Exchange Server 2003 are under no circumstances supported in a production environment. Do not attempt to deploy Exchange Server 2003 Beta in a production environment. Only deploy Exchange Server 2003 Beta in a test environment. Exchange Server 2003 will not be supported on Microsoft Windows Server 2003 in a production environment until it is publicly released.
Several features of Exchange 2000 Server, such as Instant Messaging, Chat, and Key Management Service (KMS) are no longer supported in Exchange Server 2003. Do not attempt to upgrade servers running Exchange 2000 Server with these components installed. See the section Administration later in this document for more details.
Exchange Server 2003 runs on Windows Server 2003 and Microsoft Windows® 2000 Server SP3 or later. Exchange Server 2003 has been optimized to run on Windows Server 2003, and several Exchange Server 2003 features require Windows 2003.
Exchange Server 2003 is supported in all Active Directory® directory service forest environments: native Windows 2000, native Windows 2003, or mixed Windows 2000 and Windows 2003 forests.
When running in an environment with Windows 2000 domain controllers and global catalog servers, the DCs and GCs that Exchange Server 2003 uses must all be running Windows 2000 SP3 or later. Exchange Server 2003 will not use a Windows 2000 DC or GC that is not running Windows 2000 SP3 or later. This requirement affects both Exchange Server 2003 servers and the Exchange Server 2003 version of Active Directory Connector (ADC). ADC will not work with DCs or GCs that are running a version of Windows 2000 earlier than SP3.
Note   While Exchange 2000 Server SP2 and later is supported in an environment with Windows Server 2003 domain controllers and global catalog servers, Exchange Server 2003 is the first version of Exchange Server that is supported when running on Windows Server 2003. Exchange 2000 Server is not supported on Windows Server 2003.
Exchange Server 2003 can coexist with Exchange 2000 Server and, when running in Exchange Server mixed mode, with Exchange Server 5.5 servers.
For Exchange 2000 Server, Exchange Server 2003 supports in-place upgrades.
In-place upgrades are not supported for servers running Exchange Server 5.5. To upgrade from Exchange Server 5.5 to Exchange Server 2003, you must join a server running Exchange Server 2003 to the Exchange Server 5.5 site, then move Exchange Server resources, such as mailboxes, to the server running Exchange Server 2003. Use the Exchange Server Deployment Tools to migrate from Exchange Server 5.5 to Exchange Server 2003.
While Exchange 2000 Server did support in-place upgrade from Exchange Server 5.5, the move-resources scenario is the recommended Exchange Server 5.5 to Exchange 2000 Server upgrade path.
This section describes known issues for Exchange Server 2003. These issues may impede your ability to successfully deploy and use Exchange Server. You should familiarize yourself with all of the known issues listed here prior to installing the software.
Known issues are listed based on Exchange Server component. The following sections are included:Setup
When you uninstall Exchange Server 2003, the file ese.dll is marked for deletion, but is not actually deleted. The file is not deleted until you reboot the server. If you do not reboot the server after uninstall, when you reinstall Exchange Server 2003, setup sees that ese.dll already exists on the server, and does not replace it. Because the file is marked for deletion, the next time the server is rebooted, ese.dll will be deleted. Therefore, you must reboot the server after uninstalling Exchange Server 2003, but before you reinstall.
Microsoft Outlook® Web Access does not work, and the Microsoft Exchange Server POP3 (POP3Svc) and Microsoft Exchange Server IMAP4 (IMAP4Svc) services will not start, if you install Exchange Server 2003 on a domain controller running Windows 2000, where the server was renamed prior to being promoted to a domain controller. This is because the local IWAM_ServerName and IUSR_ServerName user accounts on the DC are not renamed based on the new server name, and Exchange Server uses these accounts to run ASP.NET applications, such as the Exchange Server Mobile Browse components. When the Directory Service/Metabase Synchronization (DS2MB) process initializes, it expects to find the IWAM_ServerName and IUSR_ServerName accounts, where "ServerName" is the name that the server was renamed to. Because these accounts do not get renamed during DCPromo, DS2MB stops further replication between Active Directory and the metabase, causing Outlook Web Access to stop working and the IMAP and POP services to not start.
To get Outlook Web Access working and the POP3 and IMAP4 services to start, you must rename the local IWAM_ServerName and IUSR_ServerName accounts to reflect the new server name. For example, if the original server name was Server1, and it was renamed to DC1 prior to running DCPromo, you would need to rename the IWAM_Server1 user on the DC to IWAM_DC1, and the IUSR_Server1 user on the DC to IUSR_DC1. Once you have renamed these accounts you need to restart the inetinfo service. Outlook Web Access will now work, and the IMAP and POP services can be successfully started.
If you upgrade a server from Exchange Server 5.5 to Exchange 2000 Server, and subsequently upgrade the operating system from Windows 2000 to Windows 2003, you will receive an error message that Exchange Server 5.5 is not supported on Windows Server 2003. This error message is harmless and can be ignored.
If you run Exchange Server 2003 Beta setup with tracing enabled (using the regtrace.exe utility), Exchange Server crashes near the end of Setup. For the beta, do not run setup with tracing enabled. If tracing is already enabled, disable it prior to running Setup. If you want to enable tracing, make sure to turn it on after setup finishes.
Several features of Exchange 2000 Server, such as instant messaging, chat, and Key Management Service (KMS) are no longer supported in Exchange Server 2003. This causes the following issues when using Exchange Server 2003 to administer Exchange Server:
For the beta of Exchange Server 2003, failover will not function correctly if running on Active/Active Windows clusters. For the beta release, do not configure Exchange Server on an Active/Active Windows cluster.
Background: The index version for the Microsoft Search Service (MSSearch) has changed from Exchange 2000 Server to Exchange Server 2003. During an upgrade from Exchange 2000 Server to Exchange Server 2003, when MSSearch detects the version change, it forces a full population of all full-text indexes on the server. Repopulating all the full-text indexes on a server could place a great deal of load on the server and take a long time to complete (possibly days). To keep this from happening during an upgrade, Exchange Server 2003 pops up a dialog to remind the user about the index version change and then pauses the full population of the indexes and disables searching on the indexes until you decide to resume the index population and re-enable the indexes for searching.
This functionality does not work when upgrading a server running Exchange 2000 Server in a cluster to Exchange Server 2003 Beta. Due to the configuration of a cluster, Exchange Server 2003 Setup is unable to pause the full population of the full-text indexes. It will, however, disable searching on the indexes. After the cluster node has been upgraded to Exchange Server 2003, the Exchange Server Virtual Server has been upgraded, and the cluster resources come on-line, a full population will begin on all full-text indexes and the indexes will be disabled for searching. To avoid having the full population begin automatically, manually start and then pause a full or incremental population on all the full-text indexes on the server prior to upgrading the Exchange Virtual Server. If the indexes are already paused when you upgrade, they will remain paused and the upgrade will finish normally. After you have finished upgrading, you can manually resume building the indexes when it is convenient to do so. Once the indexes have been built, you can enable searching on the newly built indexes.
When you upgrade a cluster node from Exchange 2000 Server to Exchange Server 2003 Beta, setup installs a new version of the exres.dll file. Because this file is being used by the cluster service, a reboot is required after upgrading before the new version of exres.dll is used. After upgrading a cluster node from Windows 2000 to Exchange Server 2003, you must reboot the server.
If you install Exchange Server 2003 Beta on a cluster node running Windows 2000 SP3 with Kerberos authentication enabled, users will not be able to logon to that server with Outlook Web Access.
There is a Windows hotfix that addresses this issue for Windows 2000 Server SP3: Q329938_W2K_SP4_X86_EN.exe. Apply this hotfix before installing Exchange Server 2003 on the cluster node. For the beta of Exchange Server 2003, you can get this hotfix at the location where you downloaded Exchange Server 2003.
When creating an Exchange Server Virtual Server (EVS) using Cluster Administrator, if you specify the data directory for the EVS as the root of a drive, such as E:\, when you try to bring the System Attendant resource online, it will fail. This is because Exchange Server is adding a backslash to the specified folder name, which for a root directory results in a double backslash preceding the log file name. For Exchange Server 2003 beta, specify a data directory located in a folder other than the drive root.
If the inetinfo.exe process is stopped on a node in a cluster, the IMAP4 service (IMAP4Svc) will not restart. Instead, the Exchange Server Virtual Server will fail over to another node in the cluster. If you notice that your Exchange Server Virtual Server has failed over, check the event logs on the failed node for the following events:
Event Type: Error
Event Source: IMAP4SVC
Event Category: None
Event ID: 116
Description: The service metabase path '/LM/IMAP4SVC/' could not be opened. The data is the error code. For additional information specific to this message please visit the Microsoft Online Support site located at: http://www.microsoft.com/contentredirect.asp.
Event Type: Error
Event Source: IMAP4SVC
Event Category: General
Event ID: 1040
Description: An error occurred while starting the Microsoft Exchange Server IMAP4 Service: the call to IIS_SERVICE::IsActive() failed with error 0x426.
If you see either of these events, manually restart the IIS Admin Service (IISAdmin) on the failed node. The IMAP4 service will then be able to start.
In Exchange Server 2003, you can use Cluster Administrator to delete a System Attendant resource from an Exchange Server Virtual Server (EVS) without deleting the EVS. If you then try to create a new System Attendant resource with the same name as the deleted resource, Cluster Administrator crashes. This occurs because the MSSearch application for the EVS is not deleted when the System Attendant resource is deleted; only the MSSearch cluster resource is deleted. Because the MSSearch application already exists, when you recreate the System Attendant resource, MSSearch crashes, which also causes Cluster Administrator to crash.
For Exchange Server 2003 Beta, do not recreate a System Attendant resource with the same name as one that was deleted.
Exchange Server 2003 includes a new feature that lets you create query-based distribution groups (QDGs - see the Getting Started guide for more information on QDGs). While QDGs that were created using Exchange Server 2003 will function in an Exchange 2000 Server SP3 environment, they cannot be administered using Exchange 2000 Server administration tools. Trying to administer a QDG using Exchange 2000 Server administration tools, such as the Exchange 2000 Server version of Active Directory Users and Computers, can cause the tool to crash. You must use the Exchange Server 2003 administration tools when managing QDGs.
Mail flow problems exist on a dual-homed server running Exchange Server 2003 with two SMTP virtual servers running on Windows 2003. This configuration consists of a mail gateway configured with two network interfaces that act as the single connection point between your intranet and the Internet. Two SMTP virtual servers are configured on the server running Exchange Server, the external SMTP virtual server is configured to use the external IP address and accept incoming Internet mail; the intranet SMTP virtual server is configured to use the internal IP address and an external DNS server and it sends all external mail. You can setup this configuration manually or you can run Internet Mail Wizard to configure it. See the following URL for more details on this configuration:http://www.microsoft.com/downloads/release.asp?ReleaseID=43539.
When an Exchange Server is configured in this way on a Windows Server 2003, routing problems exist between the two SMTP virtual servers because Exchange Server incorrectly detects a mail looping situation. This issue creates problems in the following scenarios:
- POP/IMAP users connecting remotely are not able to send mail to external users.
However, remote POP/IMAP users (Outlook Express/OLK in internet Mode) connect to the external virtual server can only send to internal recipients. They cannot relay (even though they are authenticated). This is because in order to send mail to an external address, mail must be routed between the two SMTP virtual servers. The following error is returned when a remote client attempts to connect to the external SMTP virtual server and then send mail to an external users, “A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded to two recipients.”
- When an external SMTP server connects to the external SMTP virtual server and attempts to send mail to an invalid user, Exchange Server does not return an NDR.
External users that send mail to an invalid address in this Exchange Server organization do not get NDRs returned. Transport logs event 4000 "Unable to deliver message because the destination address was misconfigured as a mail loop." Again, this is because in order to return an NDR, mail must be routed from the external SMTP virtual server that accepts mail to the intranet SMTP virtual server that sends outbound mail and this routing does not work.
If you configure a server in this way manually or using the Internet Mail Wizard, you must manually enter an MX record on the internal DNS server used by the external SMTP virtual server that accepts mail from the Internet.
To configure this, enter an MX record that points to a fictitious host name. Enter an A record for the fictitious name that points to the internal IP address of the SMTP virtual server that sends outgoing mail. This configuration forces the internal DNS server to look for an MX record to route outgoing mail.
For Exchange Server 2003 Beta, if the server running Exchange Server 2003 is configured as the source bridgehead, site connector costs between Exchange Server 5.5 sites are always evaluated as 1. This causes cost-based routing to fail if the server running Exchange Server 2003 is configured as the source bridgehead for the site connector. For Exchange Server 2003 Beta, do not configure servers running Exchange Servers 2003 as source bridgeheads for site connectors.
In an Exchange Server 5.5 organization, the routing calculation server (also known as the Routing Information Daemon - RID) is the server responsible for building the Gateway Address Routing Table (GWART). The GWART is used to store connector information such as address space and routing cost. If you join a server running Exchange Server 2003 to an existing Exchange Server 5.5 site and then set the server running Exchange Server 2003 to be the routing calculation server, you need to restart the Microsoft Exchange Server Routing Engine service (RESVC). If you do not restart the service, routing for servers running Exchange Server 5.5 will not function properly, because certain attributes are not written to the Gateway Address Routing Table (GWART) until the service is restarted. If you make the server running Exchange Server 2003 the routing calculation server, make sure to restart the Routing Engine service.
It is recommended that you select a server running Exchange Server 5.5 to be the routing calculation server in a mixed mode environment. Selecting a server running Exchange Server 2003 to be the routing calculation server is not recommended. See KB article Q25809 for more information.
GB 18030 encoded messages were not supported in Exchange 2000 Server SP3, although they could be successfully routed by a server running Exchange 2000 Server SP3 with Internet Explorer 6.0 Service Pack 1 (SP1) installed. Otherwise GB 18030 encoded messages generated Non-Delivery Reports (NDRs) on servers running Exchange 2000 Server SP3.
Exchange Server 2003 supports GB 18030 encoded messages on servers with Internet Explorer 6.0 SP1 installed. If you are installing Exchange Server 2003 on a Windows 2000 server, make sure to install SP1 of Internet Explorer 6.0 if you want GB 18030 encoded messages to work. Internet Explorer 6.0 SP1 is installed by default on Windows Server 2003, so this issue only affects servers running Exchange 2000 Server with an earlier version of Internet Explorer installed.
In Exchange Server 2003, authentication between front-end Outlook Web Access servers and back-end servers defaults to Kerberos authentication. For Exchange Server 2003 Beta, Kerberos authentication sometimes fails. If you are using front-end Outlook Web Access servers, you should disable Kerberos authentication on the front-end servers.
To disable Kerberos authentication, set the HKLM\System\CurrentControlSet\Services\MSExchangeWEB\DAV\FEKerberos registry key to a DWORD value other than 1.
Outlook Web Access Help is displayed in the language specified by the user's browser. For Exchange Server 2003 Beta, Help is not available if the browser language is set to Arabic or Hebrew. To see Help in one of the other languages, users can change the language setting for their browser to a different language.
For Exchange Server 2003 Beta, Internet Explorer versions prior to version 6 do not render Outlook Web Access correctly if the browser language is set to Arabic or Hebrew. Use Internet Explorer 6 when browsing Arabic or Hebrew Outlook Web Access for Exchange Server 2003 Beta.
If you have enabled Forms Based Authentication in Exchange Server 2003 Outlook Web Access, sessions are configured to timeout after 20 minutes of inactivity. For the beta of Exchange Server 2003, users may not be prompted to log back on if their session times out. Instead they will experience problematic behavior, such as the view not changing when moving to a new calendar day.
If the Outlook Web Access S/MIME control is installed, users will receive errors if the page times out.
This issue can be resolved by having users refresh the page. Once they refresh they will see the logon page and can log back in. If users are experiencing errors or problematic behavior, the timeout cookie may have expired, and they should try refreshing their browser and logging back on to Outlook Web Access.
In order to send signed and encrypted messages with Exchange Server 2003 Outlook Web Access, users must download and install the S/MIME control from their server running Exchange Server. The S/MIME control is installed from the Options page in Outlook Web Access, by clicking the Download button under Secure Messaging. For Exchange Server 2003 Beta, clicking this button does not work if the browser security settings are set to the default level. In Internet Explorer the default level is Medium-Low for the Intranet zone and Medium for the Internet zone. Users will need to lower their security settings to download the S/MIME control. In Internet Explorer, users should change the security level for the zone (intranet or Internet, depending on how they are connecting to Outlook Web Access) to Low.
Once the security setting is set to Low, users can download the S/MIME control. Once it is installed, users should change the security level back to its original setting.
When sorting items on a server running Exchange Server by flag, Outlook Web Access and Outlook 11 may experience problems.
In Exchange Server 2003 Outlook Web Access, if you try to sort by flag in a particular folder, Outlook Web Access may hang indefinitely. If this occurs, you can prevent this from happening in the future by creating a new message, saving it to the Drafts folder, then dragging the message from the Drafts folder to the folder that is having this issue. The folder will no longer hang when sorting by flag.
In Outlook 11, if you try to sort by flag, users may receive an error message. While this problem only occurs in Exchange Server 2003 Outlook Web Access, Outlook 11 may experience this issue when used with Exchange Server 5.5, Exchange 2000 Server, or Exchange Server 2003.
Outlook Web Access allows you to enable specific sets of features on a server or for individual users. For example, you can enable only Calendar and Messaging. To set this feature segmentation per user, you modify the msExchMailboxFolderSet attribute on the User object in Active Directory. The value of this attribute determines which features are available to the user.
In Exchange 2000 Server, the decimal value for enabling all features on a per-user basis was 1023 (or 0x3FF in hexadecimal). In Exchange Server 2003, the value has changed. The new decimal value is 4294967295 (0xFFFFFFFF in hexadecimal). If you had previously enabled all features using feature segmentation, you will need to update the value of the msExchMailboxFolderSet attribute on the user object to this new value. If you do not update this value, users may not be able to use all the Outlook Web Access features.
For Exchange Server 2003 Beta, users running the Unix version of Internet Explorer 5 should always choose the Basic Experience option on the Outlook Web Access logon page. Users who choose the Rich Experience option may experience unpredictable behavior, including crashes. Make sure users running Unix Internet Explorer 5 always choose the basic experience option.
If you have not enabled forms-based authentication, users will not be able to choose the basic experience. Unix Internet Explorer 5 users should not use Outlook Web Access if forms-based authentication has not been enabled.
When running the Innoculan antivirus software on a server with Exchange Server 2003 installed, Exchange Server Mobile Browse sessions may reset, causing users to have to reconnect to Exchange Server Mobile Browse. This occurs because Innoculan marks files it has examined, which ASP.NET interprets as a file change. ASP.NET then resets the session.
To work around this issue, you can increase the amount of time that ASP.NET waits before reacting to a changed file. This is set in the Web.config file. Open the Web.config file and set the delayNotificationTimeout attribute in the <httpRuntime> section to a higher value. By default the value is 5 seconds. Consider setting it to something like 60 seconds.
For more information, see the following KB articles:
ASP.NET is part of the .NET Framework. Version 1.1 of ASP.NET or later is required for certain Exchange Server 2003 features, such as Exchange Server Mobile Browse, to function. Under certain circumstances the Access Control Lists (ACLs) set by ASP.NET may be overridden and need to be restored. There are two primary ways this can occur:
The ASP.NET component of the .NET Framework is treated differently depending on whether the .NET Framework is installed on a Windows 2000 server or a Windows Server 2003. ASP.NET is installed as part of the .NET Framework on a Windows 2000 server. With Windows Server 2003, the ASP.NET component needs to be added using Add/Remove Windows Components. The Web Service Extension for ASP.NET should be allowed by default. You can double-check that it is enabled using the Web Service Extensions node in Internet Services Manager. The ASP.NET v1.1.xxxx Web Service Extension must be set to Allow.
When you promote a server to a domain controller, or upgrade from Windows 2000 to Windows Server 2003, the ACLs set by ASP.NET are overridden. This causes any applications that require ASP.NET to break. This means that if you install Exchange Server 2003 on a domain controller that was promoted after ASP.NET was installed, or if you install on a Windows Server 2003 that was upgraded from a Windows 2000 server with the .NET Framework installed, certain Exchange Server features will not work.
To avoid this problem, install ASP.NET after promoting a DC or upgrading from Windows 2000 to Windows Server 2003.
If the ACLs do become misconfigured, you can fix this problem by running the aspnet_regiis.exe script with the -i switch.
To run aspnet_regiis.exe
The script restores the necessary ASP.NET ACLs.
For Exchange Server 2003 beta, messages sent using Exchange Server Mobile Browse are encoded using the UTF-8 character set. Encoding with other character sets, such as ksc-5601 or iso-2022-jp (JIS) are not supported in the beta.
In a cross-forest scenario (where the user account and user mailbox are located in separate Windows forests), Exchange Server Mobile Browse users will not be able to logon to their mailboxes if the domain controllers in the forest with the user accounts are running Windows 2000 SP3 or earlier. This assumes a 1-way trust between the forests. The reason for this is that Exchange Server Mobile Browse uses user principal name (UPN) logon names, and UPNs are not supported in a cross-forest scenario in Windows 2000 SP3 when there is a 1-way trust between forests.
The workaround for this issue is to make the trust between the forests a two-way trust, or upgrade all the servers in the forest with the user accounts to Windows Server 2003. You can also apply the following Windows 2000 hotfix: Q326849_W2K_SP4_X86_EN.exe. For the beta of Exchange Server 2003, you can get this hotfix at the location where you downloaded Exchange Server 2003.
If you are using a pre-SP1 version of Internet Security and Acceleration Server (ISA Server) as a front-end for proxying Server ActiveSync® requests from Pocket PC devices, synchronization will not work correctly if you have not applied service pack 1 (SP1) of ISA Server and configured a registry key. This is because ISA Server filters out some of the Options information needed by the client. Install SP1 of ISA Server if you are using ISA as a front-end, and configure the registry key as described in KB article Q304340.
When using Pocket Internet Explorer on a Pocket PC device with Exchange Server Mobile Browse, if SSL is enabled, the back button does not function properly. Pressing the back button always takes the user to the Main Menu, not back to the previous page. Users should be made aware that pressing the back button when browsing with SSL enabled always returns them to the Main Menu.
For Exchange Server Mobile Browse, several devices that are supported are treated as unsupported devices for Exchange Server 2003 Beta. The following iMode devices are supported, but are treated as unsupported devices:
When users connect to Exchange Server Mobile Browse with these devices, they will receive an error that the device is not supported. However, these devices are supported, and the error can be ignored.
If a user has not accessed a folder for at least eight days that has many thousands of items in it, Exchange Server Mobile Browse times out when the user first tries to view the folder. On that first attempt the user will receive a timeout error. Subsequent attempts to browse the folder will work normally. The number of items in the folder that causes this behavior depends on the server hardware. An average server may see this behavior with a folder containing 4,000 items. A high-end server might require many tens of thousands of items before this behavior occurs.
You can disable the User Initiated Synchronization feature for users by choosing Disable on the Exchange Server Features tab on the user object. However, for the beta of Exchange Server 2003, if the domain where the user account resides does not contain either a global catalog server or the Exchange Server users connect to for synchronization, disabling this feature does not work. Even if you disable this feature, users will still be able to synchronize their Pocket PC device. For Exchange Server 2003 Beta, the relevant attribute (msExchOmaAdminWirelessEnable) is not resolved properly across domains.
Exchange Server Web forms support Exchange Server Store views. The path for the view control has changed for Exchange Server 2003, so Web Form applications referencing the view control will stop working properly after upgrading to Exchange Server 2003. You must update any Web Form applications that reference the view control (wfview.htc) to point to the new location. The new location for wfview.htc is \Exchsrvr\exchweb\controls.