The upcoming release of Microsoft Exchange Server 2010 includes new email archiving features.  Previously the domain of third party add-on products from various software vendors, this marks the first time it has been built in to the Exchange Server product itself.

Given the long and proven history of some of the third party solutions one wonders whether Microsoft’s first attempt at a built in archiving feature will compare favorably.  Let’s take a look at what we know so far about archiving in Exchange Server 2010.

Exchange Server 2010 Archiving

There are a few pre-requisites for Exchange Server 2010 archiving to function.  Firstly, it requires Enterprise CALs for the users that will be archive enabled.  In addition, the archive mailbox is only viewable using Outlook 2010 (due for release sometime after Exchange 2010), which means Outlook 2007 and prior versions will not be able to see it, although it is visible using the Exchange 2010 Outlook Web App.

The archiving feature can be enabled on a per-mailbox basis.  Once enabled it creates a second mailbox for the user, the archive mailbox.  Mailbox items can be moved to the archive mailbox either manually or via the use of Retention Policies set by the administrator.

Unlike the primary mailbox, the archive mailbox cannot be cached by Outlook for offline access.  This reduces the file size of the cached OST file on the end user’s computer; however, this benefit is somewhat redundant because the OST file format in Outlook 2007 SP2 and Outlook 2010 has been greatly optimized and will now run quite efficiently at large sizes such as 10 gigabytes.Although the archive mailbox is a separate mailbox it is still contained within the same mailbox database as the user’s primary mailbox.

Comparison to Third Party Archiving Products

I’m going to compare Exchange 2010 archiving to third party products in general terms rather than specifically compare different products feature by feature.  Even in general terms some of the points are quite valid and may give pause to customers considering deploying Exchange 2010′s archiving feature.

Firstly the Enterprise CAL requirement means additional costs.  For a smaller organization hoping to utilize a built-in archiving feature for Exchange this additional cost can be more than the licenses for a third party product.  Unless the organization is also planning to use other features that the Enterprise CAL provides it may be wiser to choose another product.

The decentralized model of archive mailboxes is also a potential concern.  Third party archiving products offer the capability to draw all archives into a central location where they are more manageable.  Exchange 2010′s model keeps archives distributed around all of the branches of an organization where the mailbox servers are located.

The limitation of placing the archive mailbox in the same mailbox database is also somewhat disappointing.  Archives by their nature are less frequently accessed and are perfect for low cost storage.  Unfortunately with Exchange 2010 the archive mailboxes can’t be placed in a different database on slower, cheaper disk.  That said, Exchange 2010 has dramatically improved its disk performance which may mean the databases are already stored on lower cost disk.  This will vary depending on the scale of the organization.

It is also unclear as to whether the archive mailboxes are simply included with the regular Exchange mailbox backups, or if they can be separated out and backed up less often.  Again an advantage of third party products is that once items are archived they don’t necessarily need to be backed up nightly within the archiving product.

Retention and discoverability are two areas where Exchange 2010 seems to get it right.  Archives are searchable by non-IT staff (e.g. HR, Legal) via an easy to use control panel, and items of interest can be copied elsewhere for further analysis.  Furthermore, a “legal hold” can be placed on individual mailboxes or an entire organization to prevent any item deletion by end users.

Summary

Exchange Server 2010 is due for release within a few weeks and until then the full archiving feature cannot be properly assessed and understood.  However based on current information it may not be the inexpensive built-in solution they are hoping for.

Is Exchange Server 2010 Archiving a Hit or Miss?

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

There are more than a couple of situations when you may receive the error code, 0×80040005. Here are some of those situations:

1. when you cannot move, synchronize, or autoarchive messages
2. if active mail session with Exchange server was broken
3. when emailing a report using the tree email from within FRx Report Designer
4. when you use Distributed Authoring and Versioning (DAV) to query for message properties on the information store in Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003

If you are in a situation where you (1) cannot move, synchronize or autoarchive messages then you may receive the error code 0×80040005. When you try to AutoArchive messages, move messages, or synchronize items while Microsoft Outlook is connected to a Microsoft Exchange Server mailbox, you may receive the following error message:

Error while archiving folder <folder name – Inbox> in store “Archive Folders”. The source and destination folders for this operation cannot be the same.

It is possible that you receive the following message in the synchronization log:
12:51:31 Error synchronizing folder   
12:51:31 [80004005-501-0-550]   
12:51:31 The client operation failed.   
12:51:31 Microsoft Exchange Server Information Store
     
You might also receive the following error message when you attempt to copy/move:
“Can’t move the items. The item could not be moved. It was either already moved or deleted or access was denied.”

To resolve this behavior, verify that all items with attachments are either opened or deleted when you receive them.

You can use the Preview pane in Outlook to view the messages. This opens the messages and allows the scan to take place. There may be minor delays in the process while the scans occur.

In the case where (2) active mail session with Exchange server becomes broken - this may happen if xp_sendmail fails with the mail error code 0×80004005.

When you use xp_sendmail extended stored procedure to send e-mail from SQL Mail with SQL Server 2000, you might receive the following error message:
 
Server: Msg 18025, Level 16, State 1, Line 0
xp_sendmail:failedwithmailerror 0×80040005
 
You receive the same error message if you use SQL Server Agent to send email messages. However, when you use the Microsoft Outlook client on a computer that is running SQL Server (and Outlook is configured with the same MAPI profile as SQL Mail), the delivery of messages is not affected and you can successfully send e-mail.

You can experience problems described in the “Symptoms” section of this article if connection to the Microsoft Exchange server was broken during active SQL Mail session. The connection could be broken due to a sudden loss of network connectivity with an Exchange server or because of other network problems. As a result, an invalid SQL Mail session is left on an SQL Server, and SQL Server attempts to utilize it for xp_sendmail calls. Since the mail session is invalid, an error is returned.

To fix the problem without restarting the SQL Server service, you may manually stop the invalid mail session. To do so, connect to the SQL server with Microsoft SQL Server Query Analyzer or similar utility using an account with sysadmin privileges, and run the following command:
 
exec master.dbo.xp_stopmail
 
This will force the broken mail session to quit and allow new sessions to be successfully created during xp_sendmail calls.

Another situation can occur where you receive the 0×80040005 error message, “Send Message Error: -2147467259 – (Collaboration Data Objects) – e_fail (80004005)”

This error occurs when (3) emailing a report using the tree email from within FRx Report Designer.

One of the following should resolve the error:

1. Confirm that the pathing for the Output path in the Company – Information screen and pathing that has been entered in the Catalog – Output tab Filename field is a valid path.
2. When sending an attachment and using the email in the tree, a Mailbox file size limit may be reached. Remove some users from the tree or increase the size limit of the Microsoft Outlook mailbox.

Another possible circumstance when you might receive the error code 0×80040005 is (4) when you use Distributed Authoring and Versioning (DAV) to query for message properties on the information store in Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003. Then the DAV query of the information store for message properties returns the 0×80004005 error code.

A 0×80004005 (ecCallFailed) error is returned if the urn:schemas:mailheader:to property is requested. Additionally, an error is returned if there are messages in the result set that have recipients where the value of PR_EMAIL_ADDRESS is an empty string (“”).

To resolve this problem, obtain the latest service pack for Exchange Server 2003. For more information you can review article number, 836993, in the Microsoft Knowledge Base to learn more about how to the latest service packs for Exchange Server 2003.

In addition, a supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem concerning when the DAV query of the information store for message properties returns the 0×80004005 error code.

Troubleshooting Error Code 0×80040005

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

I am sure that at some point your users have come to you and complained that they can’t send email. You can take a look at the logs and also at a particular user’s setting to see if there if anything different about their profile.

Sometimes they will try to send an email but get back a message similar to the following: This message could not be sent. Try sending the message again later, or contact your network administrator. The Microsoft Exchange server is currently busy. If this message is still displayed in 30 minutes, contact your Exchange server administrator. Error is
[0x80040111-0x80040111-0x000520].

There are other situations when you may get the error code 0×80040111 such as:

• PRB: Error “ClassFactory Cannot Supply Requested Class” (80040111 …  (279129).
• Attempting to install Microsoft Windows Live OneCare.
• If you have two instances of Microsoft SQL Server 2000 on the same computer, and SQL Mail is configured with separate mail profiles on each instance.
• Move Mailbox operation is unsuccessful.
• Logons to the Microsoft Exchange server computer fail and you get “The information store could not be opened” error message.
• If the MSSQLServer Service startup account is set to the local system account and xp_startmail fails.
• Exchange 2000 Management Pack MAPI Logon Check Reports Logon Failures.

Sometimes you receive fatal error messages when you use the MsExchange Event Services (Events.exe) in Exchange Server 5.5 or in Exchange 2000 Server to process messages. This can happen when a client action spawns activation of a script and they get the following error message:

A fatal error (0×80040111) occurred in an IExchangeEventSink while processing message [Subject = "xxx"]

This is a MAPI error which translates to the MAPI_E_LOGON_FAILED error value.

This issue may occur if any one of the following conditions are true:

• At least one script was last modified by someone who shares the same alias, the same surname, or the same display name as someone else in the global address list.
• For an Exchange 2000 Server-based computer, the Exchange Event Service logs on as the local computer account instead of a service account.
• If you join an Exchange 2000 Server-based computer to the site, and then perform either of the following actions:
  o Move the mailbox that created the event scripts that are bound to a folder.
  o Move an existing Exchange Server 5.5 script to an Exchange 2000 Server-based computer.

You should first determine if there is a duplicate mailbox alias (Mixed or Pure Exchange environments). You can do this by following the steps listed below. (Remember to always backup your Registry.)

1. Determine which mailbox has a duplicate alias by clicking on the EventConfig_servername folder for the server that is receiving the errors, then see who has Owner permissions. Do this because only the owners can modify the scripts.
2. Look for duplicate names by sending a new message to the alias, and then perform a check name procedure. If more than one mailbox is returned, check the surnames to see if there are duplicates.
3. To check for ambiguity for each of those aliases:
   o Type their alias in the To line of the client and perform a Check Name.
   -Or-
   o Type =alias on the To line, then press ALT+K.
   -Or-
   o Perform a directory export of the global address list and sort on the Alias column to see if any of the owners of the EventConfig_servername folder shows multiple listings.
4. Set diagnostic logging to Maximum (5) for the Event Service. This can only be done in the registry at:
   HKEY_Local_Machine/System/CurrentControlSet/Services/MSExchangeES/Parameters

If no duplicate mailbox aliases were discovered then you should resolve known issues with permissions (Mixed or Pure Exchange environments).

If duplicate mailbox aliases were discovered then you have to decide whether you want to choose a different (unique) mailbox to edit the scripts or remove the other mailboxes from the global address list.

If the scripts are installed in mailbox folders, the next part is even more detailed if you do not have a list of which mailboxes have scripts associated with them or there are many that do. This is because even with Event Service logging turned up to Maximum (5) in the registry, the Event ID 16385 (which occurs just before the Event ID 11) says that the folder being processed is Inbox. Every mailbox has an Inbox folder. So you cannot know which mailbox has been altered by the “rogue” EventConfig owner.

1. Post or send a message to the above mailboxes in a segmented fashion to determine when the Event ID 11 occurs. Twenty percent intervals during a quiet time in the environment are suggested.
2. When you find the mailbox, simply go into the script and save it while you are logged on as a unique mailbox alias.
3. If the scripts are installed in public folders:

• Set Event Service logging to Maximum (5) in the registry.
• Post or send messages to the public folders in the same fashion as described with mailboxes above, and monitor the application log.
• Event ID 16385 tells you which folder it is processing and, in case there are multiple agents in the folder, Event ID 32773 tells you the agent that it’s calling.
• Log on to a unique mailbox that has Owner permissions on the EventConfig_servername and the public folder, then open the script, and save it.

Troubleshooting Error Code 0×80040111

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

As always, getting an error message can have different causes. And when administering the “fix” you might not solve your problem. So I will offer a couple of different solutions to problems that produce the 0x8004011D error message.

Sometimes you have cancelled the Exchange Server logon for synchronization and you then receive the 0x8004011D error message from Outlook. This situation can occur when you synchronize and then work offline or restart offline. You’ll get the following error message after you press F9 to reconnect for another synchronization and then click Cancel in the network logon dialog box:

Task “Microsoft Exchange Server” reported error (0x8004011D): “The server is not available. Contact your administrator if this condition persists.”

Microsoft has confirmed that this is a problem in Microsoft Office Outlook 2007, Microsoft Office Outlook 2003 and Microsoft Outlook 2002 Standard Edition.

You can also get the same error message – Task “Microsoft Exchange Server” reported error (0x8004011D): The server is not available. Contact your administrator if this condition persists – whenever your machine tries to connect to the Exchange Server.

Sometimes you will notice that this error message is seemingly restricted to a particular machine and is not showing up on other machines. Such is the case as when your users can log in to Outlook Web Access from all machines except one particular machine. Your first efforts at diagnostics should include testing your network connection by pinging  the Exchange Server from the problem machine. Use the IP address and Fully Qualified Domain Name.

Try to avoid having to reinstall any software such as Microsoft Office. That should be the last thing you do to correct the problem.

Sometimes you will see this error message when you have slow connections and VPN connections. You can try to delete the Exchange profile in Outlook and then recreate it. Sometimes this will correct the problem. You can also try recreating the entire user profile. Another solution which works is to add the problem user’s profile to the access control list (ACL) and then apply permissions to the user’s read information store status. After the user logs in and after verifying that the problem no longer exists you should then remove the user from the ACL. Follow the instructions below to implement this solution:

1. Verify that the problem user(s) are logged off.
2. In Exchange manager, locate the information store that contains the problem user(s) mailbox. Right click, select Properties and then select the security tab.
3. Add the problem user(s) account to the ACL and apply the “Read Information Store Status” permission.
4. Ask the user(s) to log back in, open Outlook and verify that the problem no longer exists.
5. Remove the user from the ACL.

You can also receive the 0x8004011D error code when you work offline in Microsoft Outlook. Sometimes the Send/Receive status bar may appear after about two minutes, and then you receive the error message on the Send/Receive status bar after three to five minutes.

This problem occurs when all the following conditions are true:

• You installed Microsoft Office XP Service Pack 2 (SP-2), or you installed the update that is described in the following article in the Microsoft Knowledge Base: 311744  OL2002: Messages That Have EFD or MAPI Forms Are Not Automatically Sent
• You are working offline in Microsoft Outlook.
• You are not connected to a network.
• You have the ‘Send immediately when connected’ option turned on.

The problem is fixed in Office XP Service Pack 3. You can resolve it by obtaining the latest service pack for Microsoft Office XP. Go to the following article in the Microsoft Knowledge Base http://support.microsoft.com/kb/307841/ to view information about how to download the latest Office XP Service Pack from Mircrosoft.

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described above. Apply this hotfix only to systems that are experiencing this specific problem.

This fix is a post-Office XP Service Pack 2 (SP-2) fix. To install the fix, you must have Office XP SP-2 installed. Additionally, you may have to install Windows Installer 2.0 to install this fix.

To work around this problem, turn off the ‘Send immediately when connected’ option. To do this, follow these steps:

1. Start Microsoft Outlook.
2. On the Tools menu, click Options.
3. On the Mail Setup tab, click to clear the ‘Send immediately when connected’ check box, and then click OK.

Troubleshooting Error Code 0x8004011D

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

There are many situations when you may receive the error code 0×80040115.

Such situations may include:
- An attempt to save an activity in the Microsoft Dynamics CRM client.
- The xp_sendmail extended stored procedure does not run.
- The Information Store service crashes on an Exchange Server 2003.
- RPC data may be blocked and Outlook may not start in Windows Server.
- Event ID 8207 repeatedly appears in the application log.
- Event IDs When Starting the Information Store with Blank Databases.
- Multiple Exchange Server 2007 services do not start when you upgrade.
- Microsoft Exchange Server – Sending” reported error.
- The connection to the Exchange Server computer was lost.

Here are some ways to resolve some of these errors.

Looking at the first situation where you were trying to save an activity in Microsoft Dynamics CRM 3.0 client for Microsoft Office Outlook, you may receive the following error message:

Microsoft CRM Unhandled Error Details:
Server Error in ‘/’ Application.

Exception from HRESULT: 0×80040115.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.Runtime.InteropServices.COMException:
Exception from HRESULT: 0×80040115.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Stack Trace:

[COMException (0x80040115): Exception from HRESULT: 0x80040115.]
Microsoft.Crm.Platform.ComProxy.CRMContactClass.Create(CUserAuth& Caller, String Contact) +0
Microsoft.Crm.Application.Platform.Contact.InternalCreate(String xml) +268
Microsoft.Crm.Application.Platform.Entity.Create() +109
Microsoft.Crm.Application.Forms.AppForm.RaiseDataEvent(FormEventId eventId) +408
Microsoft.Crm.Application.Forms.EndUserForm.Initialize(Entity entity) +57
Microsoft.Crm.Application.Forms.CustomizableForm.Execute(Entity entity, String formId, String formType) +83
Microsoft.Crm.Application.Forms.CustomizableForm.Execute(Entity entity) +13
Microsoft.Crm.Web.SFA.ContactDetailPage.ConfigureForm() +244
Microsoft.Crm.Application.Controls.AppPage.OnPreRender(EventArgs e) +29
System.Web.UI.Control.PreRenderRecursiveInternal() +54 System.Web.UI.Page.ProcessRequestMain() +1499

Microsoft CRM Platform Error Report:
Error Description:
Exception from HRESULT: 0×80040115.

Error Details:
Exception from HRESULT: 0×80040115.

Error Number:
0×80040115

Source File:
Not available

Line Number:
Not available

This problem occurs if the following conditions are true:

• You try to save one of the following activities:
  o Contact
  o Task
  o Appointment
  o Service
• You click Go Offline in the Microsoft Dynamics CRM client for Outlook, and then you disconnect the computer that is running the Microsoft Dynamics CRM client for Outlook from the network.

The cause of the problem is because a MAPI_E_NETWORK_ERROR error stops the IMsgStore->OpenEntry function.

Note The IMsgStore->OpenEntry function is defined in the OutlookItemFinder.cpp file.

You can correct the problem by enabling the Use Cached Exchange Mode feature in Outlook. To do this, follow these steps:

1. Start Outlook.
2. On the Tools menu, click Account Settings.
3. Click the e-mail account that you use, and then click Change.
4. Click to select the Use Cached Exchange Mode check box, and then click Next.
5. Click Finish.
6. Click Close.

In the second situation, where the xp_sendmail extended stored procedure does not run, you may have tried to send an e-mail message by using the xp_sendmail extended stored procedure on a computer that was running Microsoft SQL Server 2000 Service Pack 2 (SP2) or later. The result was that the xp_sendmail extended stored procedure did not run successfully. You most likely received the following error message:

Server: Msg 18025, Level 16, State 1, Line 0
xp_sendmail: failed with mail error 0×80040115

This problem typically occurs when the following two conditions are present:

• There is a loss of network connectivity between the computer that is running Microsoft SQL Server 2000 and the computer that run Microsoft Exchange Server.
• The Exchange server is restarted after the first execution of the xp_sendmail extended stored procedure on instance of SQL Server where the error occurred.

You can resolve this problem by obtaining the latest service pack for Microsoft SQL Server 2000. For more information, review article 290211 in the Microsoft Knowledge Base.

Additionally, there is a Hotfix available on the Microsoft Support web site.

Microsoft has confirmed that this is a problem in the following Microsoft products:

• Microsoft SQL Server 2000 Desktop Engine
• Microsoft SQL Server 2000 Service Pack 2
• Microsoft SQL Server 2000 Service Pack 3
• Microsoft SQL Server 2000 Personal Edition Service Pack 3

This problem was first corrected in Microsoft SQL Server 2000 Service Pack 4.

To work around this problem, verify the network connectivity, and then resend the mail. You can set up the retry option for the xp_sendmail extended stored procedure by configuring the registry entries or by adding retry logic to your application code. To do this, use one of the following methods:

Method 1: Configure the retry option for the xp_sendmail extended stored procedure.

Method 2: Add retry logic to your application code.

When you send an e-mail message by using the xp_sendmail extended stored procedure, the xp_sendmail extended stored procedure makes many calls to the MAPI API. However, the retry option in the Microsoft hotfix is only added for a single call that caused the failure with the following error message:

HRESULT = 0×80040115

More information can be found on the Microsoft website.

Troubleshooting Error Code 0×80040115

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Have your users ever complained about not being able to send email that had large attachments?

Sometimes your end users will try to send emails that contain large files that are maybe ten (10) to twenty (20) megabytes or larger. After they hit the submit button they’ll get an error message that goes something like: “The message being sent exceeds the message size established for this user.” You can check the user’s outbox and the message is still there.

This can happen with Exchange using Outlook. Outlook may or may not be setup in Exchange server cached mode. One thing you can do is to have the Exchange system administrator check the global send size limits. Then compare those limits to the size of the outbound email attachment. If the email attachment exceeds that size limit then you can have your user try zipping the file(s) so as to reduce the total size of the attachment(s). Then try re-sending the email.

The user may also have to consider splitting the attachment into smaller pieces and then resend those smaller chunks in separate emails. Sometimes users are sending PowerPoint attachments which can be very large when graphics and images especially are added to the presentation. The user could break the presentation into a sequence of three or four sections and then resend those sections separately.

Every once in a while you have the situation where you’ve attempted to preempt a potential problem by cleaning up a folder such as the Sent Items folder. One admin had reported that they removed a large message from the Sent Items folder after they surmised that the large message was not going to get past the recipient’s firewall and that the message was too large. After doing so they then started getting the 0×80040610 error code. They then tried to cancel all (pending transactions) but received another error indicating that the task was cancelled before it was completed.

It turned out that the cancelled email was still stuck in the Microsoft Exchange Server because it had exceeded the file size limit – as discussed previously. Deleting the file resolved the issue and stopped the error message from being generated.

A possible solution would have been to add a new profile through the mail icon in the control panel. Once successful then you could move the mail from the old profile into the new one.

You can also check your email settings. It’s possible that you might have the following parameter settings and still need to make some changes.

get-sendconnector showing all send connectors have a maxmessagesize of 150MB

get-receiveconnector showing all receive connectors have a maxmessagesize of 150MB

get-transportconfig showing a MaxSendSize to be unlimited

get-Mailbox also shows MaxSendSize is unlimited

If this is the case you may still be able to receive large emails.

You can restart the Microsoft exchange transport service and server to make your setting changes permanent. You can also try setting the TransportConfig to unlimited and Mailbox limits to a fixed value.

Make changes to TransportConfig and Mailbox limits by going to the Exchange Management Console (the GUI tool). From there, go to the Recipient Configuration area and then to the Mailboxes. Select a user and then edit their properties. Select the “Mail Flow Settings” tab.  Highlight the “Message Size Restrictions” and click the properties button.  If you see the that Sending Message Size and Receiving Message Size “Maximum Message Size in KB” are unchecked, then this can result in  an “unlimited” value for the get-Mailbox report of MaxMessageSize. 

You can also set your own value by checking both boxes and entering a value such as 102400 (100 MB in KB). Then save your new settings.  You should now be able to send large files larger up to 100 megabytes in size.  Change your remaining user values as appropriate. You should now be able to see a value of 100MB for the get-Mailbox parameter in the Exchange Management Shell for all mailboxes that have been changed using that value.

Note that you can change the values for all users or you can set the TransportConfig value and it will apply to all users. For example,

Set-TransportConfig -MaxReceiveSize 100MB -MaxSendSize 100MB

Another reported workaround is to stop the Edge Synchronization:  configure the hub transporter to allow the desired size limits and then restart the Edge Sync with the updated hub transporter configuration.

Troubleshooting Error Code 0×80040610

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators