Exchange Server Pro » Exchange 2003

Error: Outlook Was Unable to Recover Some or All of the Items in this Folder

Paul Cunningham — Wed, 14 Dec 2011 10:13:26 +0000

While attempting to restore items from the Outlook recoverable deleted items you may encounter the following error message.

Outlook was unable to recover some or all of the items in this folder. Make sure you have the required permissions to recover items in this folder, and try again. If the problem persists, contact your administrator.

The error may occur when you attempt to recover a folder that contains a large number of sub-folders or mail items in it.

On the Exchange Server you may see a corresponding Application event log entry similar to this:

Log Name:      Application
Source:        MSExchangeIS
Date:          11/14/2011 12:57:59 PM
Event ID:      9646
Task Category: General
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      exchangeserver.domain.local
Description:
Mapi session "3bbea118-07e3-4746-b7bf-0e5b65e28314" exceeded the maximum of 500 objects of type "objtFolder".

This can occur due to the default limits configured on the Exchange Server for the number of items that can be opened by a single MAPI session. In the example above the MAPI session was trying to open more than the default 500 allowed objects of type “objtFolder” (in other words, Folders).

The solution is provided by Microsoft in this support article, which refers to Exchange Server 2003 but applies to later versions as well.

Open Regedit and navigate to \\HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
If the key “MaxObjsPerMapiSession” does not already exist, right-click on ParametersSystem and create a new key of that name.
Create a new DWORD value with a name matching the object type in the event log error on your server (eg “objtFolder” in this example)
Set the DWORD value to a decimal value higher than the default. For the case above I first tried 1000, then 10000 when that did not work.
Wait 15-30 minutes for the registry change to take effect, then retry the Outlook operation.

You may find that you need to try gradually increasing the value until you can successfully recover the items in Outlook. You may also find that after you’ve removed one limit that another object type’s limit may also suddenly come into play, so always check your event log for new errors identifying additional object types that you may need to add a registry value for.

After you’ve successfully recovered the Outlook items revert the registry keys to their default values (listed in the Microsoft support article above) to prevent issues with server resources in the future.

Get more Exchange Server tips at ExchangeServerPro.com

Using Test-Mailflow with Exchange 2003 Servers

Paul Cunningham — Sun, 04 Dec 2011 12:32:49 +0000

One of the challenges of managing a large Exchange Server environment is that you often need to support multiple versions of Exchange.

That means that often when you write a PowerShell script you need to account for servers running different versions and adjust accordingly. It can turn a simple scripting exercise into a big task.

Recently I was looking at ways to include our Exchange 2003 servers in some monitoring scripts that are already running for Exchange 2007/2010 servers. I wanted to perform a mail flow test for the Exchange 2003 servers, because that is a test that (if successful) very quickly confirms a lot of the elements involved in email availability are in fact healthy (ie the server is up, reachable, accepting SMTP connections, processing mail queues, the Information Store is running, and more).

For Exchange 2007/2010 the Test-Mailflow cmdlet can be used for these. You can build it into a health check script if you want to. But if you try to run it against an Exchange 2003 server you’ll get an error like this:

[PS] C:\>Test-Mailflow -Identity EX2007SERVER -TargetMailboxServer EX2003SERVER

Test-Mailflow : "EX2003SERVER" is running a previous version of Exchange and does not support this task.
At line:1 char:14
+ Test-Mailflow <<<<  -Identity EX2007SERVER -TargetMailboxServer EX2003SERVER
    + CategoryInfo          : InvalidArgument: (:) [Test-Mailflow], OperationOnOldServerException
    + FullyQualifiedErrorId : 642F2C5C,Microsoft.Exchange.Monitoring.TestMailFlow

However, if the Exchange 2003 server is in the same organization you can use a different parameter with Test-Mailflow to achieve the same result. All you need is an email address for one of the mailboxes on the Exchange 2003 server. You might want to create a mailbox on each of your Exchange 2003 servers (or even each of the databases on those servers) specifically for this purpose.

Then you simply run the Test-Mailflow cmdlet with the -TargetEmailAddress parameter instead of the -TargetMailboxServer parameter.

[PS] C:\>Test-Mailflow -Identity EX2007SERVER -TargetEmailAddress EX2003SERVER_test@domain.com

TestMailflowResult         MessageLatencyTime          IsRemoteTest
------------------         ------------------          ------------
Success                    00:00:19.5014893            True

As you can see this is a nice, simple way to test your Exchange 2003 server health using PowerShell.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010 FAQ: How to Install the Exchange 2003 System Manager Tools

Paul Cunningham — Thu, 16 Jun 2011 12:00:47 +0000

Question: Is there a way to install Exchange 2003 System Manager on a server after an Exchange Server 2010 installation?

In short, no there isn’t.

Exchange Server 2010 will only install on 64-bit versions of Windows Server 2008 or 2008 R2. The Exchange 2010 management tools can also be installed on 64-bit versions of Windows 7.

The Exchange 2003 System Manager is a 32-bit only application and can only be installed on 32-bit operating systems.

However, if you need the Exchange 2003 tools on your administrative workstation while you are in a co-existence phase of your Exchange 2010 upgrade, you can install them in XP Mode on Windows 7.

Get more Exchange Server tips at ExchangeServerPro.com

Configuring Co-Existence for Exchange 2003 and Exchange 2010

Paul Cunningham — Thu, 05 May 2011 12:38:52 +0000

This post is an excerpt from the Exchange Server 2003 to 2010 Migration Guide.

We are approaching the stage of the migration project where the Exchange 2010 servers begin to perform production roles, such as message routing, remote access, and hosting mailboxes.

This period is referred to as the “co-existence” period.

For some organizations a co-existence period is not necessary, because they are small enough that 100% of the services and data on Exchange 2003 can be migrated across to Exchange 2010 within a single outage window.

For example a small business with just a few dozen, small mailboxes could perform the entire migration in a single weekend with no business hours impact. Such organizations can skip the co-existence phase if they wish to, which reduces the amount of configuration work required.

However for the rest of us a co-existence period is required, which means there are some necessary configurations to put in place first before any production services or data are migrated to Exchange 2010.

Establishing the Legacy Namespace

The legacy namespace is the name that will be used by Exchange 2003 mailbox users to access Outlook Web Access after the remote access namespace is transitioned to the internet-facing Exchange 2010 Client Access server.

What this means is that Outlook Web Access/App connections are first made to the Client Access server. Exchange 2010 mailbox users are proxied as normal to the appropriate Mailbox server. However Exchange 2003 mailbox users are redirected to the legacy namespace instead.

Some people find the legacy namespace to be a confusing topic. In effect the legacy namespace is simply another DNS name, published with ISA Server or another firewall, that legacy (Exchange 2003) mailbox users are redirected to for Outlook Web Access.

Creating the Legacy DNS Record

The legacy name can be anything you like however the name that is commonly chosen is simply “legacy”, or in this example scenario “legacy.exchangeserverpro.net”.

This legacy name should be included in your Exchange 2010 SSL certificate when it is provisioned.

Create a DNS record for the legacy name in your public DNS zone. If you are using split DNS you should also create the record in your internal DNS zone.

The public IP address that the DNS record is created for can be the same as the public IP address of your primary remote access name (e.g. mail.exchangeserverpro.net) if you are using ISA Server 2006 to publish Exchange remote access. ISA Server is capable of publishing the different names to different internal servers using the same web listener.

If you are using a different firewall or a simple NAT router then you may need to configure the legacy namespace on a separate public IP address.

Tip: If you are using split DNS take a look at how your existing OWA public name is configured in your internal DNS zone. If it uses the public IP then do the same with your legacy name, however if it uses the internal IP then you should configure the legacy name to the internal IP as well for the internal DNS zone.

Configuring the OWA Virtual Directory for Legacy Redirection

The OWA Virtual Directory on the internet-facing Client Access server must be configured with the legacy URL to redirect users to.

Open the Exchange Management Shell and run the Set-OWAVirtualDirectory cmdlet with the following parameters:

-Identity is the name of the OWA Virtual Directory being modified
-Exchange2003URL is the legacy URL to redirect Exchange 2003 mailbox users to

Set-OwaVirtualDirectory -Identity "esp-ho-ex2010a\owa (Default Web Site)" -Exchange2003Url https://legacy.exchangeserverpro.net/exchange

Assigning the SSL Certificate to Exchange Server 2003

The Exchange 2003 front end server needs to be configured with the new SAN certificate that was provisioned for Exchange 2010. This is so that remote access connections to the legacy namespace can occur over SSL without any certificate errors or warnings.

To export the certificate from Exchange Server 2010 launch the Exchange Management Shell and run the following commands.

First determine the thumbprint of the SAN certificate that is installed.

Get-ExchangeCertificate

Thumbprint                                Services   Subject
----------                                --------   -------
4DE8E0AC4ECB09623645842752FAA80C4160BF0B  ...WS.     CN=mail.exchangeserverpro.net, OU=IT Department, O=Exchange Ser...
F539B9045F765F9F0DFDE1EA9CB4BACAAE2C6C54  IP..S.     CN=esp-ho-ex2010a

In this example the thumbprint is “4DE8E0AC4ECB09623645842752FAA80C4160BF0B”.

Next export the certificate to a file by running the following command. Note this is a single-line command.

$file = Export-ExchangeCertificate -Thumbprint 4DE8E0AC4ECB09623645842752FAA80C4160BF0B -BinaryEncoded:$true -Password (Get-Credential).password

A popup dialog appears for you to enter a password to protect the private key. The username field is not important but requires something to be entered in it for the dialog to accept, so just enter “username” and then a strong password.

Next run the following command to generate the file.

Set-Content -Path "C:\Admin\ex2010cert.pfx" -Value $file.FileData -Encoding Byte

Open Windows Explorer and look at the location you specified as the –Path parameter in the above command, and you will now see the exported certificate.

Copy the file to the Exchange Server 2003 front end server.

On the Exchange 2003 front end server launch mmc.exe and add the Certificates snap-in to the console, choosing the Computer account context.

Choose Local Computer and then click Finish, Close, and OK to return to the console.

Right-click Personal and choose All Tasks -> Import. Step through the Certificate Import Wizard choosing the certificate file that was copied from the Exchange Server 2010 server.

Enter the password that you used when the certificate was exported from Exchange Server 2010.

Place the certificate in the Personal certificate store.

Complete the wizard and confirm that the import was successful.

The imported certificate will now appear alongside the existing SSL certificate on the front end server, if you had one installed already.

The certificate now needs to be added to the HTTPS binding for the IIS website on the Exchange 2003 front end server.

Launch IIS Manager from the Administrative Tools menu of the Exchange 2003 front end server.

Right-click the web site that hosts the Exchange 2003 virtual directories, and then choose Properties.

Select the Directory Security tab and click on Server Certificate.

Click Next to step through the welcome page. Choose Replace the current certificate, and then click Next to continue.

Select the SSL certificate that was imported from the Exchange 2010 server and click Next to continue.

Confirm your selection and then click Next again, and then Finish.

Click OK to apply the close the web site properties dialog box.

You should now test your Exchange 2003 remote access (e.g. Outlook Web Access) to verify that the new certificate is working correctly.

Get more Exchange Server tips at ExchangeServerPro.com

Why Haven’t You Upgraded Your Exchange Servers Yet?

Paul Cunningham — Fri, 29 Apr 2011 03:00:22 +0000

I ran a poll here on the site a couple of weeks ago to find out which versions of Exchange Server people were currently running. Even though some people had trouble answering because they manage multiple environments there were still 182 people who responded to the poll.

The results are interesting to see.

Results of Reader Poll on Exchange Server Versions

Exchange Server 2010, which RTM’ed in November 2009, comes in at 50% of the market according to the responses received.

Exchange Server 2007 was lagging in 3rd place early in the poll but overtook Exchange 2003 to reach 26% of the vote. I actually thought this would be lower by now because the move from 2007 to 2010 is not as complex as migrating from Exchange 2003 to 2010.

But as I think on it more it probably makes sense. After all I was still helping customers migrate to Exchange Server 2007 at least six months after Exchange 2010 was released, and continue to work with Exchange Server 2007 customers today.

Exchange Server 2003 came in third place which makes a lot of sense, although the 20% share of the vote was definitely a surprise for me. I expected there to be some element of “skip every second version” out there in the market but if those customers have been waiting for Exchange Server 2010 it has been out long enough now to have done something about migrating. For those who haven’t perhaps there are good reasons such as application compatibility or just the sheer scale of their environment that is slowing them down for now.

I almost didn’t include Exchange 2000 in the poll. Luckily I did and it received a handful of votes. I’m genuinely concerned about those customers since not only are they running an unsupported version of Exchange but they are also presumably running it on an unsupported version of Windows (2000). And unless they’ve converted those servers to VM’s they are also very likely running on out of warranty hardware.

So what about you, why haven’t you upgraded your Exchange Servers yet?

Get more Exchange Server tips at ExchangeServerPro.com

Poll: Which Version of Exchange Server Are You Running?

Paul Cunningham — Fri, 01 Apr 2011 03:00:59 +0000

I still see a lot of activity in Exchange 2003 and 2007 forums online so I thought it would be interesting to see which version of Exchange Server the readers of this site are running at the moment. Please cast your vote in the poll below.

Note: if you’re currently in the middle of a migration project just choose the version that you’re migrating to right now.

Note: There is a poll embedded within this post, please visit the site to participate in this post's poll.

If you’d like to provide a bit more information about which version you’re running and why please leave a comment below.

Get more Exchange Server tips at ExchangeServerPro.com

Free Sample Chapter from the Exchange Server 2003 to 2010 Migration Guide

Paul Cunningham — Sun, 20 Feb 2011 10:30:16 +0000

The part of an Exchange Server 2010 migration project that is most important is the planning stage. During this phase of the project the critical information about an Exchange environment is discovered that helps to properly plan out a successful migration.

The Exchange Server 2003 to 2010 Migration Guide includes a comprehensive planning chapter that walks you through the discovery process, including which tools and software to use, so that you learn the critical information about your environment to avoid causing problems during the upgrade.

I’m pleased to announce that this valuable planning chapter of the guide is now available as a free download to subscribers of Exchange Server Pro. To get instant access to the free sample as well as free weekly Exchange Server tips and tutorials simply enter your best email address in the form below.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010 FAQ: Is Direct Exchange Migration from 2003 to 2010 Possible Without Upgrading to 2007?

Paul Cunningham — Sun, 20 Feb 2011 09:41:41 +0000

Question: Is Direct Exchange Migration from 2003 to 2010 Possible Without Upgrading to 2007?

Yes. Migrating from Exchange Server 2003 to Exchange Server 2010 is a fully supported upgrade path, and is the simplest way to migrate from 2003 to 2010. There is no requirement to migrate to Exchange 2007 first.

However, something to be aware of is that it is recommended to apply the Exchange 2007 schema update to your Active Directory forest before you apply the Exchange 2010 schema update, even if you do not plan to deploy any Exchange 2007 servers.

By applying the Exchange 2007 schema update first you make it possible to install Exchange 2007 servers later on if you need to for any reason, for example to maintain compatibility with a particular application. Basically it is a fail-safe method of ensuring that if you encounter any compatibility problems with Exchange 2010 you can still migrate away from Exchange 2003 and use a mix of 2007 and 2010 servers instead.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange 2010 FAQ: How Do I Migrate Public Folders to Exchange Server 2010?

Paul Cunningham — Sun, 23 Jan 2011 04:33:50 +0000

For most Exchange Server organizations migrating public folders is as simple as moving replicas from one server to another. This can be achieved using one of two methods:

Moving all Public Folder replicas using the Exchange 2003 System Manager console
Moving all Public Folder replicas using the Exchange 2010 Management Shell

Either method will work in just about any scenario, it just comes down to which one you’re most comfortable using.

Moving all Public Folder Replicas to Exchange Server 2010 Using the Exchange 2003 System Manager Console

In this example scenario the public folders hosted on the Head Office Exchange 2003 server are being moved to the Head Office Exchange 2010 Mailbox server.

As with mailbox migrations public folder migrations can generate heavy disk I/O on the source server, and will generate a lot of transaction logging that consumes free disk space on the target server.

On an Exchange 2003 server open Exchange System Manager. Navigate to the server that currently hosts the public folder replicas, and browse to the public folder Instances folder of the public folder database.

Note the public folder instances currently on this server.

Public Folder Instances shown in the Exchange 2003 System Manager console

Right-click the public folder database and choose Move All Replicas.

Move all Public Folder Replicas

Choose the public folder database to move the replicas to.

Choose the database to move the Public Folder replicas to

A warning appears that the move may take a lot of time depending on the amount of public folder content to be moved. Click OK to begin.

Note that moving Public Folder replicas can take some time

You can refresh the public folder instances folder to monitor progress. This operation can take some time, even for a small amount of public folder content. When the public folder instances displays an empty list the operation has completed.

All public folder replicas have been moved

Moving all Public Folder Replicas to Exchange Server 2010 Using the Exchange Management Shell

Public folder replicas can also be moved using the Exchange Management Shell. In this example the public folders hosted on the Branch Office Exchange 2003 server will be moved to the Branch Office Exchange 2010 Mailbox server.

On the Exchange 2010 server open the Exchange Management Shell. Navigate to the scripts folder of the Exchange installation folder.

[PS] C:\>cd $env:exchangeinstallpath\scripts

Microsoft has supplied a PowerShell script called MoveAllReplicas.ps1 for moving public folder replicas. Run the script with the following parameters:

-Server is the name of the Exchange 2003 server
-NewServer is the name of the Exchange 2010 server

Note that this is a single-line command run from the folder containing the scripts.

[PS] C:\Program Files\Microsoft\Exchange Server\V14\scripts>.\MoveAllReplicas.ps1 -Server ESP-BR-DC -NewServer ESP-BR-EX2010

You can use the same method as with the Exchange System Manager console technique to determine when all replicas have been moved.

Get more Exchange Server tips at ExchangeServerPro.com

Fixing Mail-Enabled Object Aliases for Exchange Server 2010 Migration

Paul Cunningham — Thu, 06 Jan 2011 12:26:31 +0000

This article is an excerpt from the Exchange Server 2003 to 2010 Migration Guide.

Exchange Server 2010 treats some object attributes differently than Exchange Server 2003. The most common issue that this causes is invalid aliases on mailbox users, however it can also occur for contacts and groups.

Exchange Server 2010 applies the following rules to aliases:

Valid values are: Strings formed with characters from A to Z (uppercase or lowercase), digits from 0 to 9, !, #, $, %, &, ‘, *, +, -, /, =, ?, ^, _, `, {, |, } or ~. One or more periods may be embedded in an alias, but each period should be preceded and followed by at least one of the other characters. Unicode characters from U+00A1 to U+00FF are also valid in an alias, but they will be mapped to a best-fit US-ASCII string in the e-mail address, which is generated from such an alias.

You can see which mailboxes have invalid aliases by running the following command from the Exchange Management Shell.

Get-Mailbox -resultsize unlimited | findstr "Warning"

If there are only a few mailbox users with invalid aliases you can correct them manually using Active Directory Users & Computers on an Exchange 2003 server.

Exchange 2003 Mailbox User Alias

However if there are a lot of mailbox users that need aliases fixed you can use a script provided by Microsoft to automatically correct them. The Fix-Alias.ps1 script is available to download here:

Fix-alias.PS1 script

The Fix-Alias.ps1 script has a built in help function to explain how to use it.


[PS] C:\Admin>.\fix-alias.ps1 -help

This script will find objects of the specified type that contain a space in the aliasIt will remove the space from the alias and update the object

Both the search character and the replacement character can be changed using the advanced options

Advanced Options:

-Type       : Used to specifiy the get- command that is run to find the objects (Mailbox,Distributiongroup,Mailcontact)
-Resultsize : Used to specifiy a result size other than the default of "Unlimited"
-Search     : Used to specify the character / sting to search for
-Replace    : Used to specify the replacement character
-Add        : Used to provide the get- command with addtional switch options
-Help       : Display this help message

Examples:

fix-alias.ps1 -type MailContact -Search "@" -Replace "_" -add "-OrganizationalUnit 'My Ou'"

For example, to fix all of the mailbox users in the organization that have spaces in their alias, and replace them with periods, we would run this command:

[PS] C:\Admin>.\fix-alias.ps1 -type Mailbox -search " " -replace "."

The script will then output which objects were found and fixed.

Found Object to Fix: Alannah Shaw
New Alias of Object: Alannah.Shaw

Found Object to Fix: Linda Dowden
New Alias of Object: Linda.Dowden

Found Object to Fix: Olive Weeks
New Alias of Object: Olive.Weeks

Be careful when changing mailbox user aliases. If the Exchange 2003 Recipient Policy uses the alias to generate the user’s email address then a change to the alias may result in a change in primary SMTP address. Check your Recipient Policies first before making changes to aliases using the Fix-Alias.ps1 script.

Get more Exchange Server tips at ExchangeServerPro.com

Exchange Server Pro » Exchange 2003

Error: Outlook Was Unable to Recover Some or All of the Items in this Folder

Related posts:

Using Test-Mailflow with Exchange 2003 Servers

Related posts:

Exchange 2010 FAQ: How to Install the Exchange 2003 System Manager Tools

Related posts:

Configuring Co-Existence for Exchange 2003 and Exchange 2010

Establishing the Legacy Namespace

Creating the Legacy DNS Record

Configuring the OWA Virtual Directory for Legacy Redirection

Assigning the SSL Certificate to Exchange Server 2003

Related posts:

Why Haven’t You Upgraded Your Exchange Servers Yet?

Related posts:

Poll: Which Version of Exchange Server Are You Running?

Related posts:

Free Sample Chapter from the Exchange Server 2003 to 2010 Migration Guide

Related posts:

Exchange 2010 FAQ: Is Direct Exchange Migration from 2003 to 2010 Possible Without Upgrading to 2007?

Related posts:

Exchange 2010 FAQ: How Do I Migrate Public Folders to Exchange Server 2010?

Moving all Public Folder Replicas to Exchange Server 2010 Using the Exchange 2003 System Manager Console

Moving all Public Folder Replicas to Exchange Server 2010 Using the Exchange Management Shell

Related posts:

Fixing Mail-Enabled Object Aliases for Exchange Server 2010 Migration

Related posts: