Explore technical insights and updates for Office 365 and Exchange Server. Priasoft empowers IT professionals with reliable solutions and expertise.

Email messages take a long time to send and receive using Outlook 2003 with Exchange 2010

Priasoft Migration Suite for Exchange (PMSE)

UDP notification support was removed from Exchange 2010. As a result, Outlook 2003 can only use polling notifications in online mode. This will result in a slight delay in updates to item status (30 seconds on average with up to a one-minute delay) when changes are made to items in a mailbox accessed by Outlook 2003. There are two workarounds for this issue:

  • Use Outlook 2003 in Cached Exchange Mode.
  • Adjust the polling interval on the Client Access server. Note: This will impact the performance of the Client Access server.

To resolve this problem, use one of the following methods.

Option 1: Install Update Rollup 1 For Exchange Server 2010

After you install the update, you must add the following registry data to the server by using the Client Access role.

Start Registry Editor.

Locate and then click to select the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem

Note: Create the \ParametersSystem registry subkey if it does not exist.

Add the following registry data to the server:

Value type: REG_DWORD
Value name: Maximum Polling Frequency
Value data: any integer between 5000 and 120000 (decimal value)

The registry change is dynamically detected. Therefore, the new settings will be applied to any new connections that clients make after the change is made. If you want to make sure that the new settings are applied to all clients, you should recycle the Microsoft Exchange RPC Client Access service because connections from clients can remain alive for a long time.

Outlook 2003 does not poll the Exchange Server 2010 server in intervals that are less than 10 seconds. Therefore, any value less than 10000 will generally have the same effect.

This change does not reinstate UDP communication between Exchange Server 2010 and Outlook 2003. This change only enables polling to occur more frequently between Exchange Server 2010 and Outlook 2003.

Option 2: Use cached mode with your Outlook 2003 profile

If you cannot install Update Rollup 1 for Exchange Server 2010 at this time, use cached mode for your Outlook 2003 profile. The cached mode synchronization process uses a different architecture to update folders that are in your mailbox.

To configure your profile to use cached mode, follow these steps:

  1. Exit Outlook 2003 if it is running.
  2. In Control Panel, start Mail.
  3. Click E-mail Accounts.
  4. Click to select View or change existing e-mail accounts, and then click Next.
  5. Select your Microsoft Exchange Server account, and then click Change.
  6. Click the Use Cached Exchange Mode check box to enable cached mode.
  7. Click Next, and then click Finish.
  8. Start Outlook 2003.

Outlook 2003 Client Configuration with Exchange 2010

Priasoft Migration Suite for Exchange (PMSE)

When you upgrade to Exchange 2010, your clients running Outlook 2007 or later versions will automatically be compatible with the change to RPC Client Access services in Exchange 2010, since they support RPC encryption by default. Outlook 2003 doesn’t use RPC encryption; however, RPC Client Access requires it by default. If you haven’t turned off RPC encryption, your users will need to configure Outlook 2003 for RPC encryption.

Note: When using the Priasoft Profile Update Manager to update Outlook client profiles, Outlook 2003 clients are configured to support RPC encryption to avoid these issues.

Symptoms of this problem include the following error messages:

  • Cannot start Microsoft Office Outlook. Unable to open the Office window. The set of folders could not be opened.
  • Unable to open your default e-mail folders. The information store could not be opened.
  • If your users are using Cached Exchange Mode, Office won’t display an error, but will start in disconnected mode.

To correct this use the following workarounds:

Option 1: Disable the encryption requirement on all CAS servers

To disable the required encryption between Outlook and Exchange, follow these steps:

On the server that is running Exchange 2010, run the following command in the Exchange Management Shell:

Set-RpcClientAccess –Server Exchange_server_name –EncryptionRequired $False

Note The Exchange_server_name placeholder represents the name of an Exchange Server 2010-based server that has the Client Access Server role.

Rerun this command for each Exchange 2010-based server that has the Client Access Server role.

Option 2: Manually update or create your Outlook profile with RPC encryption

  1. In Control Panel, open the Mail item.
  2. Click Show Profiles.
  3. Select your profile, and then click Properties.
  4. Click E-mail Accounts.
  5. Select View or change existing e-mail accounts, and then click Next.
  6. Select the Microsoft Exchange Server account, and then click Change.
  7. In the dialog box that contains your mailbox server and user name, click More Settings.
  8. In the Microsoft Exchange Server dialog box, click the Security tab.
  9. Click to select the Encrypt data between Microsoft Office Outlook and Microsoft Exchange Server check box, and then click OK.
  10. Click Next, and then click Finish.
  11. Click Close, and then click OK.

Option 3: Deploy a Group Policy setting to update existing Outlook profiles with RPC encryption

From a client perspective, deploying the Outlook-Exchange encryption setting is probably the simplest solution for organizations that have many Outlook clients. This solution involves a single change on a server (domain controller), and your clients are automatically updated after the policy is downloaded to the client.

The default Group Policy template (Outlk11.adm) for Outlook 2003 Service Pack 3 (SP3) does not contain the policy setting that controls the setting for encryption between Outlook and Exchange. Therefore, you must use a custom Group Policy template to update existing Outlook 2003 profiles so that RPC encryption is used in Outlook-Exchange communication.

You can download the required Outlook 2003 policy template here.

For more detailed information on Outlook and RPC encryption see the follow Microsoft page.

Exchange 2010 SP1 almost here.. But you can get the beta of SP1 now.

Priasoft Migration Suite for Exchange (PMSE)

The Exchange team has released Exchange 2010 SP1 beta to the public today. If you have a LAB and would like to test some of the new features you can download it from here.

Issues to be considered while thinking about moving mailboxes to Exchange 2010 using the Microsoft native tools

Priasoft Migration Suite for Exchange (PMSE)

Below is a table of the issues to be considered while thinking about moving mailboxes using the Microsoft native tools in both the ‘upgrade’ and ‘deployment’ scenarios supported by Microsoft.

Note: If you’re using the Priasoft Migration Suite for Exchange this article does not apply to you.

Exchange 2003 To 2010

  • You need to use “move request” cmdlets in 2010 shell to move the mailboxes.
  • Move requests are performed by the Microsoft Exchange Mailbox Replication Service (MRS) that runs on all Client Access servers (CAS). Therefore, CAS servers are busy moving mailboxes and not servicing clients’ requests.
  • If you implement Exchange 2010 as an upgrade, some features of Exchange 2010 will not be available until the migration is completed and the organization in moved to a native mode state.
  • You must never try to manage a 2010 mailbox using a 2003 management tool or snap in
  • You can’t use 2003 System Manager.
  • You must be careful to use a split administration model while co-existing to not cause problems with migrated objects.
  • The mailbox move is offline, which means that the users can’t access the emails while it is moved.
  • No roll-back support – If something goes wrong you may need to go back to tape to restore the mailbox
  • No support for native tools – if they don’t work they don’t work.
  • No Outlook client profile automation for migrated mailboxes. No automatic enabling of RPC encryption for Outlook 2003 based clients. You will need to do them manually or you will need to disable RPC encryption on Exchange 2010 (not recommended)
  • No Public Folder migration tools
  • No distribution group migration tools
  • You can’t move mailboxes if running Exchange 2003 SP1 or earlier, you must update all servers to 2003 SP2+
  • You can’t perform message tracking configuration tasks between Exchange 2010 and Exchange 2003
  • You must use Exchange 2003 messaging tracking tools within your Exchange 2003 organization, and Exchange 2010 messaging tracking tools within your Exchange 2010
  • Side-by-side management for Exchange Server 2003 and Exchange 2010 management tools isn’t supported, because Exchange Server 2003 management tools can only be run on 32-bit machines
  • In order to do Cross-forest move requests must create mail-enabled users with the required attributes in the target forest or it won’t work
  • Depending on the scenario you just may be able to preserve mailbox folder delegates and send-on behalf of delegates
  • If upgrading, you must run the setup /PrepareLegacyExchangePermissions command so that the Exchange 2003 Recipient Update Service functions correctly
  • If upgrading, you are required to update the Active Directory schema for Exchange Server 2010
  • If upgrading, you must Upgrade Custom LDAP Filters to OPATH Filters

Exchange 2007 To 2010

  • You can use 2010 console or “move request” cmdlets in 2010 shell to move the mailboxes.
  • If you implement Exchange 2010 in mixed mode, some features of Exchange 2010 will not be available until the migration is completed and the organization in moved to a native mode state.
  • Move requests are performed by the Microsoft Exchange Mailbox Replication Service (MRS) that runs on all Client Access servers (CAS). Therefore, CAS servers are busy moving mailboxes and not servicing clients’ requests.
  • You can’t use “move-mailbox” cmdlet in 2007 shell.
  • No roll-back support – If something goes wrong you may need to go back to tape to restore the mailbox
  • No support for native tools – if they don’t work they don’t work.
  • The mailbox move is online, which means that the users can be online while the move happens.
  • You can’t move mailboxes from 2007 SP1 or earlier, the source should run 2007 SP2+
  • Exchange 2007 Mailbox databases can’t be managed from the EMC in Exchange 2010
  • No Public Folder migration tools
  • No distribution group migration tools
  • No Outlook client profile automation for migrated mailboxes. No automatic enabling of RPC encryption for Outlook 2003 based clients. You will need to do them manually or you will need to disable RPC encryption on Exchange 2010 (not recommended)
  • The EMC in Exchange 2010 can’t manage Exchange 2007 mobile devices
  • Exchange 2007 Mailbox databases can’t be managed from the EMC in Exchange 2010
  • You can’t use message tracking configuration tasks between Exchange 2010 and Exchange 2007
  • You must use Exchange 2007 messaging tracking tools within your Exchange 2007 servers, and Exchange 2010 messaging tracking tools within your Exchange 2010 servers.
  • Exchange 2010 and Exchange 2007 servers can only be viewed from their corresponding version of the EMC
  • In order to schedule Cross-forest move requests must create mail-enabled users with the required attributes in the target forest or it won’t work
  • If upgrading, you are required to update the Active Directory schema for Exchange Server 2010
  • Depending on the scenario you just may be able to preserve mailbox folder delegates and send-on behalf of delegates

Exchange 5.5 And 2000 To 2010

  • Not supported by Exchange 2010 native tools
  • If you want to move to Exchange 2010 using native tools from Exchange 5.5 you must first migrate to Exchange 2003/2007 then to Exchange 2010
  • If you want to move to Exchange 2010 using native tools from Exchange 2000 you must first migrate to Exchange 2003/2007 then to Exchange 2010

In short, it’s not as simple as tossing in a CD. Can it be done? Sure, would we want to do it? Nope.

We highly recommend you consider the resource forest model for Exchange 2010 to avoid trying to mix the old with the new. This model, in our opinion, allows the most flexibility during migration, allows you to build your Exchange organization to your needs, and provides benefits well into the future. It also helps to reduce risk. Something we all like!

This is not a complete list of issues nor should it be used as a roadmap to moving to Exchange 2010. We are providing this simply as a comparison and we do not take any responsibility whatsoever for the information contained. You are encouraged to do your own due diligence and research.

Exchange Adoption Patterns

Priasoft Migration Suite for Exchange (PMSE)

Despite the advantages of moving to Exchange Server 2010, will organizations using an old software product want to upgrade to a newly-released version? It all depends on the organization type. There are different organization types when it comes to adopting software:

  • Early adopters jump onto the software bandwagon as soon as the software is released. Needless to say, they are far and few between and will usually have a special relationship with the software manufacturer.
  • Common adopters wait for others to test the software release and find all of its potential bugs. This usually coincides with the release of the first service pack for the software product.
  • Conservatives will wait well after the software has been released, often after the release of multiple service packs, before they make their move.
  • Ultra-conservatives will wait until the very last minute before they move to the next version of the product and when they do, they won’t usually jump onto the very latest version of the product.

This cycle is repeated every time a new version of a product is released.

Regardless of which version your choose we have the tools and experience to move you from Exchange 5.5, 2000, 2003, 2007, and 2010 to Exchange 2000, 2003, 2007, 2010, and 2013…

Exchange 2010 servers with no Internet Access.. Timeout Issues

Priasoft Migration Suite for Exchange (PMSE)
Exchange services timeout or long wait times for services or application to start up. This problem occurs when a server has no internet access or occasionally when a server has limited internet access. The cause of this problem is likely related to a routine check of the Certificate Revocation List (CRL) for .NET assemblies. In this post, I will provide some details regarding how CRL check affects Exchange server services and applications and how some registry settings can contribute to the problem (and solution). See here for more information