Blog: Exchange 2003

I was working on an SBS 2003 server that had e-mails for one user that would not deliver.  They were stuck in the Local Delivery Queue in Exchange 2003 in a retry state.  I tried to force connection, but they would never budge. 

I turned on diagnostic logging to get more information about what was going on in the Event Logs.  What I saw was “EcLocallyDiliverMsg to the store failed.  Error code: -1605, Event ID 327”. 

Some investigating seemed to point to a problem with the user’s mailbox, and that we would need to rebuild the user’s mailbox.  I exported all of the user’s mail to a PST file, deleted the mailbox, recreated the mailbox, and imported the PST file back in.  The mail remained stuck in the Local Delivery Queue.

While rebuilding the mailbox was the first part to resolving the problem, the second part came from a blog at www.thecyberwolfe.com/blog/?p=665.  This person explained that they had to recategorize the mail so that it would get to the new mailbox by doing the following in the registry of the server: [more]

  1. Stop the SMTP service.
  2. Open Regedit and navigate to the following key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SmtpSvc
  3. Create a subkey named “Queuing”
  4. Select Queuing and on right hand pane create new dword value with name “ResetMessageStatus” with value 1 in hexadecimal.
  5. Restart the SMTP service – check the queues and see if mail is being delivered. Also check the account mailbox at this point.
  6. Once all the mails are delivered to that user, stop the SMTP service and change the value for “ResetMessageStatus” to 0 and start the SMTP service.

 

We recently became aware of a problem with Exchange 2010 users being unable to set their out of office settings.  With their legacy Exchange 2003 mailboxes, they could set out of office.

When trying to set out of office within Outlook, users would get an error message that the Exchange server could not be contacted.  Performing the “Test e-mail autoconfiguration” kept failing to connect to the server with HTTP status code 401 Unauthorized.  It was also noted that OWA would not allow logins because the login credentials would not work for anyone.

After trying to troubleshoot permission problems within IIS of the mail server, I eventually came across this thread:[more] http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/36662e7c-8c4a-44dc-85d9-eb7fab1d8b49/

I ran powershell as an administrator on the server, and typed in the following:

  • Import-Module ServerManager
  • Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy

It appears that this command re-imports many IIS modules.  In the article, it has a –restart at the end, but I left it off to prevent the server from rebooting.  It was not necessary in my case in order to resolve all of the issues with OWA/OOF/Autoconfiguration.


 

This is a followup to the November 18th post concerning limits on how many Outlook rules can be created.  The limit is actually on the amount of storage the active rules take up.  Exchange 2003 has a fixed limit of 32KB.  Exchange 2007 has a default limit of 64KB, but it can be increased to as high as 256KB.  This is specified as a mailbox attribute called RulesQuota and can be changed with the Set-Mailbox Exchange Management Shell command.  The Set-Mailbox command is documented at http://technet.microsoft.com/en-us/library/bb123981.aspx

Here are examples that list the RulesQuota setting for each mailbox and set the quota for all mailboxes to 256KB. [more]

Get-Mailbox | ft DisplayName,RulesQuota

Get-Mailbox | Set-Mailbox -RulesQuota 256KB

And here is an example of how to set the RulesQuota on just one mailbox, conetrixuser’s, to 128KB.

Get-Mailbox | Where-Object {$_.Alias -eq "conetrixuser"} | Set-Mailbox -RulesQuota 128KB


 

Recently I was cleaning up some Exchange mail-enabled contacts and moving them to different OU’s.  I had to create a new contact and kept getting an error for a duplicate email address.  I couldn’t find the duplicate using the normal search methods, so after some digging I found this site that provided a custom LDAP query: [more]

http://www.danlance.co.uk/index.cfm/2007/11/14/How-to-find-the-user--entity-an-email-address-is-associated-with-in-Exchange-2003

Basically you search for attribute “(proxyAddresses=smtp:user@domain.com)” to give you the object with this email address.


 

There is a limit on how many rules you can create in Outlook.  This limit is actually based on how much space the rules take up.  The error message says “"There is not enough space on the Microsoft Exchange Server to store all of your rules", even though there is plenty of space on the drive, in the Exchange databases, etc.  According to http://support.microsoft.com/kb/241325, this is a limitation and applies to Exchange 5.0 through Exchange 2003 and Outlook 97 through Outlook 2002.  It looks like Exchange 2007 and Outlook 2007 are not affected.  That article has a few (virtually useless) pointers on how reduce the amount of space the rules take up.

Note: There is a followup to this post that provides more details and instructions on how to increase the number of rules allowed in Exchange 2007.


 

We recently had a customer that switched Internet service providers.  After making the switch, users were getting “sending delayed” messages from the Exchange server.  The problem turned out to be caused by mis-configured DNS settings in the Exchange 2003 SMTP service.  Some e-mails appeared to be going through fine, while others were delayed and eventually dropped.  Sometimes, messages would go through, the other person would respond, and then they’d get a delayed notification for the originally sent message.  After some e-mails that were sent to CoNetrix were completely dropped, I started looking more closely at the SMTP service configuration.  I went through every setting and eventually found some entries for the old ISP's DNS servers buried in the following location: [more]

Servers -> SERVERNAME -> Protocols -> SMTP -> Default SMTP Virtual Server -> Properties -> Delivery tab -> Advanced -> Configure

This configure allows you to specify “external DNS servers”.  Apparently, based on the name, someone thought the real “external” DNS servers should be used (instead of the local DNS service that uses the external servers as forwarders).  I removed the old ISP server entries and replaced them with the external DNS servers of the new ISP as a test.  Once I did this, e-mail started sending immediately.  I then changed the entry to the local IP of the server (so the local DNS service would be used).  Things continued to work.  Setting those DNS entries is not part of our normal server setup procedures, so I'm not sure where the DNS entries originally came from.  They may have been populated by some "wizard", so keep the SMTP DNS settings in mind if you ever have a similar problem.


 

Microsoft has changed the query syntax for creating Exchange Address Lists and Email Address Policies in Exchange 2007. In Exchange 2003, all recipient filters were created with LDAP queries. In Exchange 2007, a new filter syntax called OPATH has been introduced. OPATH is easier to write and makes queries easier to understand, but any ALs or EAPs that are carried over as part of a migration from Exchange 2k/2k3 to 2k7 must be updated to use OPATH instead of LDAP. Here is an example of such a conversion:

LDAP: 
(&(&(&(&(mailnickname=*)(|(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))))))
(objectCategory=user)(physicalDeliveryOfficeName=morton*)))

OPATH:
( ( ( Alias -ne $null ) -and ( ( ObjectCategory -like 'person' ) -and ( ObjectClass -eq 'user' ) -and ( recipientType -eq 'UserMailbox' ) ) ) -and ( ObjectCategory -like 'user' ) -and ( Office -like 'morton*' ) )

To save a lot of time by avoiding doing these conversions by hand you can use the LDAP to OPATH filter conversion script script provided by the Microsoft Exchange Team.


 

When restoring a Microsoft Exchange 2003 database, be sure an actual database file exists to restore to.  A restoration of the Exchange Information Store is not a file restore, so the files already need to be in place.  Beginning from scratch in a disaster recovery scenario, you will need to:

  • Install Exchange (since the Exchange installation directories should not be included as part of the file system restore)
  • Patch Exchange with the same Service Packs and Patches that were previously installed
  • Mount the Information Store (empty at the time) – this will create the necessary empty databases
  • Dismount the Information Store (and set it to be able to overwritten by a restore procedure)
  • Run the recovery of the information store
If all goes well, your Exchange installation should be back and running.

 

Use caution when installing and SSL certificate for OWA or OMA on a clustered Exchange server. When you configure Microsoft Outlook Web Access to use a Secure Sockets Layer (SSL) connection to a Microsoft Exchange Server 2003 computer, you may notice a dramatic increase in CPU usage by the Lsass.exe process and by the Resrcmon.exe process. The only way to get the process back in check is to reboot the server. This problem occurs on an Exchange 2003 computer that is running in a Microsoft Windows Server 2003-based cluster. [more]
 
Additionally, an Error event that is similar to the following is logged in the Application log:
Event Type: Error
Event Source: MSExchangeCluster
Event Category: Services 
Event ID: 1014
Date: Date
Time: Time
User: N/A
Computer: Computer Name
Description: Exchange HTTP Virtual Server Instance - (GENESIS): IsAlive checking for this resource failed due to timeout

The solution is to install Exchange 2003 SP2 or you can call MS for the hotfix. I actually like the SSL termination on the ISA server approach a little better. If the SSL tunnel is terminated on the ISA server, you can reinitiate another SSL tunnel with another internal certificate OR you can redirect the traffic to port 80 on the inside interface. Terminating the SSL connection on the ISA server offloads processing from the Exchange server, which is usually a good idea.