Category Archives: Exchange Server

Exchange Server

Exchange 2007: Exploring Global message size restrictions

Leave a comment

Exchange 2003

In Exchange 2003 you set the global message size restrictions are set with Exchange System Manager under Global Settings, Message Delivery:

022207_2052_Exchange2001

These settings are written to the Message Delivery object in the configuration partition in Active Directory. The object has the distinguished name (DN):

CN=Message Delivery,CN=Global Settings,CN=<org name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<domain>

022207_2052_Exchange2002

The attributes written are the following:

GUI Name

Active Directory Attribute

Sending message size

submissionContLength

Receiving message size

delivContLength

Recipient limits

msExchRecipLimit

Exchange 2007

In Exchange 2007 these settings are set using the Set-TransportConfig cmdlet. To view the settings you use the Get-TransportConfig cmdlet:

022207_2052_Exchange2003

These settings are written to the Transport Settings object in Active Directory. The object has the following DN:

CN=Transport Settings,CN=<org name>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<domain>

The same attributes are used but on a different object.

PowerShell Name

Active Directory Attribute

MaxSendSize

submissionContLength

MaxReceiveSize

delivContLength

MaxRecipientEnvelopeLimit

msExchRecipLimit

Exchange 2007 comes with a setting of ‘unlimited’ for all these values.

Co-existence

As mentioned, Exchange 2007 uses ‘unlimited’ as the default setting. But there are a few situations where these limits do not work as expected.

These situations are:

  • If you have both Exchange 2003 and Exchange 2007 servers in your Exchange organization
  • If you previously had Exchange 2003 and are now running Exchange 2007, and had a period of co-existence between the two systems.
  • If you previously had Exchange 2003 and are now running Exchange 2007, but have not had co-existence between the two systems.

If you have been in one of these situations it is a good chance that your global message limits are not working as expected. The reason for this is that if the Exchange 2007 Transport Configuration is set to unlimited, the Exchange 2007 store will read the old Exchange 2003 value. This means that if your Exchange 2003 value is set to 10 MB and the Exchange 2003 value is set to unlimited, you actually have a global message limit of 10 MB.

The situations when this might occur are listed above, and the reason is that the value is set in different places in Exchange 2003 and 2007 and may be “left behind” when you remove Exchange 2003. Or may have been left behind when you removed Exchange 2003.

Workaround

To fix this issue when you are in a co-existence situation, make sure the two values are synchronized. Set them to the same value using ESM for Exchange 2003 and the Set-TransportConfig cmdlet for Exchange 2007. When you are ready to remove Exchange 2003 completely, set the limits in ESM to unlimited. This is the same as Not Set in Active Directory, meaning no vale to read. That way there is no vale for the Exchange 2007 store to read and it uses the Transport Config value, whatever it is set to (including unlimited).

If you already have removed Exchange 2003 and are experiencing this problem, use ADSI edit to remove the values from submissionContLength, delivContLength and msExchRecipLimit on the Message Delivery object in the Configuration partition. Exchange 2007 will now heed the Transport Config values.

Microsoft is planning to resolve the problem with the Exchange 2007 store reading the old value in Service Pack 1 for Exchange 2007.

Note: There are also several other message size limits defined in Exchange 2003 and Exchange 2007. Connectors, users, SMTP Virtual Servers can also have limits. The limits discussed here are the global message limits.

Some more info here:

http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=943981&SiteID=17

Exchange Server

Exploring Exchange 2007 Mail-enabled contacts

Leave a comment

In Exchange 2007 a mail-enabled contact represents a recipient outside your own Exchange organization. They can be recipients on your Domino server or external recipients with a partner etc. A mail-enabled contact always has at least two addresses, but can have several. One or more are addresses from you own SMTP domain that let you see the contact in the Global Address List (GAL) and send mail to it. The other is the “real” address, namely the address that Exchange forwards the message to. This is usually an address outside your own SMTP domain.

On a mail-enabled contact you have two options for setting properties for the addresses; Set as Reply and Set as External. Set as Reply configures which address should be specified as the reply address when someone wants to reply to the message that was sent to the contact. This was known as the Primary SMTP address in Exchange 2000/2003. You can set one reply address for each address type, e.g. SMTP or Notes. Exchange requires that you have a primary, or reply address, for each address type.

Set as External is a little more interesting. It specifies where the message will end up; it’s final address. As mentioned above, a contact can have several addresses from you own SMTP domain. When a message is received by Exchange sent to one of these addresses, Exchange will look up the external address and forward the message to that address. In effect, the internal addresses are aliases for this external address. The address selected as the external address is stored in the targetAddress attribute in Active Directory. You can only have one address that is marked as external.

The addresses discussed here need not be SMTP addresses; both reply and external addresses can be either SMTP or another type.

Only contacts have the Set as External option, regular mailboxes do not need a target address since the message will be delivered directly to a store in your own Exchange organization.

Exchange Server

Testing Exchange ActiveSync with Internet Explorer

Leave a comment
1. Open Internet Explorer. In the Address bar, type https://published_server_name/Microsoft-Server-Activesync, where published_server_name is the published name of your OWA server (the name your end users will type).

2. Type the user name and information that you want to authenticate.

3. If you receive an Error 501/505 “Not implemented” or “Not supported” error message, Exchange ActiveSync is working properly.

Exchange Server

Exchange, SharePoint Services and ActiveSync Administration…

Leave a comment
Running Exchange 2003 and SharePoint Services on the same machine can be a challenge, as is well documented:
I recently tried to accomplish this, but without much success.
First some background. I was trying to run Exchange 2003 Standard Edition with OWA/OMA and EAS and SharePoint Services 2.0 on the same server, which was also a Domain Controller. Actually, it was the only server in the network.
Things started out great, I installed Exchange and performed the steps outlines in KB817379 (http://support.microsoft.com/kb/817379/), which I had to do to get OMA and EAS to work since I did not have a Front-End Exchange server. After testing all the Exchange services I proceeded with installing SharePoint Services. It installed without incident, but then the trouble started. OWA was not working, the same for OMA and EAS. WSS, however, was working. I started troubleshooting and soon found the article I linked to at the beginning of this post. Following the steps in it I was able to get OWA working, but not OMA and EAS. Every time I tried to sync a phone or access OMA I got an error in the event log that said HTTP 400 Bad request. Bad request means a malformed request was sent to the server.
Literally, for days, I search the net and finally had to put in a call to Microsoft PSS. The technician and I spent even more days looking at logfiles and traces of communication between server and clients. We were stomped. I was seriously beginning to contemplate reinstalling the server from scratch. But then we found something.
If you read article KB817379, in step 21 you see the value of the new VDir registry key you will create. Not that the article explicitly states that it should be /exchange-oma, with a forward slash. When we looked at the trace logs from Exchange we found this:
As you can see we had double forward slashes. This was the cause of the Bad Request message. An HTTP GET requestcontaining two slahes is obviously malformed. When I removed the slash from the VDir value in the registry and restarted IIS all services worked.
When this problem was resovled I installed the ActiveSync Mobile Administrator. That was also pretty hard to get working together with WSS, but I succeded.
Exchange Server

Finding free space in Exchange Server 2003 Databases

Leave a comment
Finding out how much free space (white space) an Exchange database has is something I regularly do. I want to show you two ways you can get this information.

First of, you can use ESEUTIL /MS <database name> to dump the free space information, but this requires that the database is dismounted. That is not always practical, since users may want to read some email while you check for free space.

The second way is to view the Application log of the Exchange server. When Exchange finishes online defragmentation, which is scheduled to run each night by default, it logs an event with ID 1221 in the Application log. The source can either be MSExchangeIS Mailbox Store or MSExchangeIS Public Store, dependig on whether the store is a mailbox or a public folder store. A typical 1221 event looks like this:

Type:         Information
Event:        1221
Date Time:    11.07.2006 06:00:00
Source:       MSExchangeIS Mailbox Store
ComputerName: SERVER1
Category:     General
User:         N/A
Description:  The database “Storage Group Astore1” has 659 megabytes of free space after online defragmentation has terminated.

Another neat trick is to use the eventquery.vbs tool to dump all the recent 1221 events so you can easily see all your databases. A sample commmand to dumpt the events from the last 24 hrs would be:

cscript c:windowssystem32eventquery.vbs /L Application /V /FI “ID eq 1221” /FI “DATETIME eq 07/11/06,01:00:01AM-07/11/06,11:59:59PM” /FO LIST

Exchange Server

Exchange group relationships in a multi-domain forest

Leave a comment
In a multi-domain forest with Exchange 2000/2003 installed there are some special group relationships.
Each domain for which DomainPrep has been run, has the following Exchange related groups:
  • Exchange Domain Servers (Global Group)
  • Exchange Enterprise Servers (Domain Local Group)

Exchange Enterprise Servers
Purpose: Group all Exchange servers in a specific Enterprise (organization/forest)
This group has the follwing members:
– The computer account of all Exchange servers in the organization
– The Exchange Domain Servers group from all domains where DomainPrep has been run

Exchange Domain Servers
Purpose: Group all Exchange Servers in a specified domain
This group has the following members:
– The computer account of all Exchange servers in the domain where the group exists

Errors
When adding a new Recipient Update Serveice to a domain in a multi-domain forest, that previously has not had Exchange, it is quite usual to get the following errors in the application log on the Exchange server (Exchange server is usually located in another domain):

Source:  MSExchangeAL
Category: LDAP Operations
Event ID: 8270
Description: LDAP returned the error [32] Insufficient Rights when importing the transaction
dn: <GUID=A907D19B-18F7-4098-95AB-A8E029C1634C>
changetype: Modify
member:add:<GUID=E480D07A-1A37-4D43-BC52-9A59958F3DD9>

In this event the dn: <GUID> is the GUID of the ‘Exchange Enterprise Servers’ group in the domain specified in the event. The member:add:<GUID> is the GUID of the ‘Exchange Domain servers group’ from another domain.
Probably a domain that was recently added to the forest. You will see this error for each of the other domains in the forest. The event will be repeated but with a different GUID in the member:add field.

You will also see this error:

Source:  MSExchangeAL
Category: LDAP Operations
Event ID: 8270
Description: LDAP returned the error [32] Insufficient Rights when importing the transaction
dn: <SID=0102000000000005200000002A020000>
changetype: Modify
member:add:<GUID=E480D07A-1A37-4D43-BC52-9A59958F3DD9>

In this event the <SID> is the SID of the ‘Pre-Windows 2000 Compatible Access’ group in the domain that is specified in the event (dc=xxx,dc=xxx),and the member:add:<GUID> is the GUID of the ‘Exchange Domain Servers’ group in one of the other domains in the forest. You will see this error for each of the other domains in the forest. The event will be repeated but with a different GUID in the member:add field.
These errors are most likely due to incorrect permissions in the target domain’s Active Directory.
The permissions are not correctly set or all information in not yet replicated.

Thus we can deduce the follwing member relationships:
Group Name:                          Memebership:
Exchange Domain Servers         All Exchange Servers in the group’s domain
Exchange Enterprise Servers      Exchange Domain Servers from each additional domain in the forest
Pre-Windows 2000 Compatible    Access Exchange Domain Servers from each additional domain in the forest

There is also a KB article that deals with this here:

Missing permissions cause the Recipient Update Service not to process accounts in Exchange 2000 Server and Exchange Server 2003

Exchange Server

ExMerge and Outlook 2003 PST Files

Leave a comment

Recently I was trying to import some PST files to an Exchange 2003 server using ExMerge. The PST files had been collected from clients that had previously been running POP3 accounts using various versions of Outlook. The import was part of a migration process where we moved from these POP3 accounts to Exchange 2003. Earlier we upgraded all clients to Outlook 2003 and created profiles for Exchange. Although all the clients were running Outlook 2003 now, some PST files had been created with previous versions of Outlook and some with Outlook 2003. As it turned out, this was a problem.

Upon starting the import job I immedialey started to get failures in ExMerge. This was unusual since I had verified all the PST filenames and made sure they matched the mailbox name in the Exchange database. I exmained the ExMerge log and found these errors:

Merging data from file ‘E:EXMERGEDATAUSER.PST’ to mailbox ‘User’ (‘USER’) on server ‘SERVER1’.
Error configuring message service (MSPST MS)(MAPI_E_EXTENDED_ERROR)(CMapiSession::CreateEMSPSTProfile)
Errors encountered. Copy process aborted for mailbox ‘User’ (‘USER’).
I had never seen this particular error before so I started to investigate.
After some research I found out that Microsoft changed the format of the PST and OST files in Outlook 2003 to eliminate the problems with the 2GB limits on these files that the previous verions of Outlook were hampered by. The new Unicode PST/OST files can be up to 20 GB and are in Unicode by default. The older versions of Outlook user ANSI. If you want to know more about this feature I suggest the fillowing links:
http://support.microsoft.com/kb/830336/
http://support.microsoft.com/kb/832925/
Combining this information with the error from the ExMerge log (CreateEMSPSTProfile), I guessed that maybe ExMerge could not read this new Unicode format. This was indeed the case, as the Knowledge Base article 823176 proved:
“The ExMerge utility does not support Unicode .pst files. If you export data from Outlook 2003, the default .pst format is Unicode. To work around this issue, create an ANSI .pst file. This is a .pst file that is compatible with Outlook 97 and with Outlook 2003.”
Here is the link to the article if you want to read all of it:
http://support.microsoft.com/kb/823176
The only soultion left to me in this case was to manually convert the new Unicode PST files to ANSI PST files. This was a very tedious process, that had to be done with Outlook 2003. First creating an ANSI PST file and the importing the Unicode file, and finally importing that file with ExMerge into the Exchange store. I could not find any utility to do this automatically or one to convert the file. Luckily for me there were only a few files out of the total that had to be converted.
The reason that I write this blog post is partly to share an interesting discovery with my peers, but also beacuse the error that ExMerge logs (CreateEMSPSTProfile) is not documented anywhere as being caused by an Outlook 2003 Unicode PST file. I think that it should be and so I blogged about it here. Hopefully Google will index this post soon and it will be available when someone has the same problem as I did.