There's a new property in town, called LegacyJournalingMigrationEnabled. It is FALSE by default, but if set to TRUE you can have Exchange Server 2003 Envelope Journaling sent to a mailbox hosted on Exchange Server 2007 or 2010. To get the full advantage of this you MUST install an Exchange Server 2003 hotfix discussed here. I hope you enjoy it, it's been a much needed feature.

"Initialization failed
The following error occurred when getting user information for 'domain.com\alias':
The operations couldn't be performed because object 'domain.com\alias' couldn't be found on 'somedomaincontroller.domain.com'. It was running the command 'Get-LogonUser'."

This issue can occur when the Netbios name for your domain contains a dotted notation. Generally, Netbios domains traditionally are one word values (in the sense of what we consider as "Internet" domains, such as DOMAIN. Netbios domain names, however, supported a character set which included the period, '.' and so there are a number of organization out there who may have had their Netbios domain name set up as DOMAIN.COM, or COMPANY.DOMAIN, or any such combination that included a period or "dotted" notation.

You will need to contact us for an Interim Update that can be applied to resolve this issue. It should also be fixed in Exchange Server 2010 RU4 but at this time, we haven't gotten RU3 out the door so it will be a few months.

I've also seen this resolve issues with ActiveSync to back end E2K3 servers given the same "dotted" Netbios domain. Given that there are a number of potential components in Exchange that this could impact, if you have a dotted Netbios domain and are having some very odd problems with Exchange 2010, please give us a call (or apply RU4 if it's available when you read this).

 Note: You MUST open a support incident with Microsoft Exchange Server Support. To make this as easy as possible, please refer to KB 981033 and provide the Exchange Rollup version you are currently running to get the correct fix.

EDIT: Exchange Server 2010 RU4 is now out, see http://msexchangeteam.com/archive/2010/06/17/455191.aspx. It contains the fix to resolve this issue.

In Exchange Server 2007, this property supports two values:

• NoCreate
• MayCreate

Unfortunately at this time, the Exchange Server 2007 documentation for this feature found here was airlifted from the Exchange Server 2010 documentation and is not accurate. I'm working to get that rectified now.

NoCreate
This does just what it sounds like. We will NEVER create a named property under this condition. Similar to the behavior of Exchange Server 2007 SP1 RU9.

MayCreate
This options attempts to allow anonymous and authenticated mail submissions to have their X-Headers promoted to named properties. If we fail to promote, the message should be submitted anyway, hence "MayCreate". This will keep us from running into the previous behavior where messages could queue and/or ultimately NDR.

Impact
So what's the point of all this? Named properties are used for many thing, but a big impact for many is the use of named properties where POP and IMAP clients are concerned. Because Exchange Server 2007 does not keep the Mime for a message around, nor does it keep a full Mime Structure of the originally submitted messages, we will reconstruct the headers of a message when going through item (MAPI) to MIME conversion, IOW, when downloading a message via POP or IMAP.

If the X-Header on a message has never been promoted to a named property then it will not show up when RETRieving or FETCHing the message via POP or IMAP. Because the named property table is managed on a per database basis, once a named property has been promoted into a specific database it will always be provided to the POP/IMAP client.

Problems changing back to NoCreate
I wanted to edit this post because I've noticed that changing from NoCreate to MayCreate on Exchange Server 2007 results in the inability to change back to NoCreate. This has been bugged and scheduled to be released in a future rollup. instead it must be manually modified via AD using LDP, ADSIEDIT or your favorite AD modification tool.

This value is stored on the msExchTransportSettingsFlags property for the CN=Transport Settings, CN=<ORG NAME>, CN=Microsoft Exchange, CN=Services, CN=Configuration, CN=<DOMAIN> container. This is a bitwise flag that controls several different parameters. NoCreate and MustCreate are controlled by the 21st and 22nd bits. Once set to MayCreate, to set it back to NoCreate, you must subtract 3145728 from the current value.

Note: I *HIGHLY* suggest that you copy down the value of msExchTransportSettingsFlags down BEFORE you modify it, in lieu of any mistakes made in changing the value.

So what happens if you start Queue Viewer, it doesn't try to connect to your local Edge Server instance and only allows you to select a Hub Transport Server (unsuccessfully I might add)? This was an issue I was pinged on earlier today.

Queue Viewer attempts to determine if it's on an Edge Server or not, and it does this by calling into some other classes that provide this information among other things. They will query the following key:

HKLM\SOFTWARE\MICROSOFT\Exchange\v8.0\EdgeTransportRole\ConfiguredVersion

This should be a string value with the properly installed Exchange version.

If this key is missing and without it's proper value then it will cause Queue Viewer to behave this way, even though Queue related management tasks from the powershell will function just fine.

Now, in my case we were at Exchange Server 2007 SP2 so the correct value was 8.2.176.2. Essentially, this should match the UnpackedVersion in the registry.

At this point we only seem to keep track of the major installed versions so rollups which are applied will not increment this value. One last word of caution. If this value is missing, you may have some other things going on because this value should be updated/added by a successful setup. In our case, everything on the server was working fine except queue viewer but it's still cause for investigation.

We see this most often with 3rd party agents that interop w/unmanaged modules. Load up performance monitor and add the following two counters

• .Net CLR Memory/# Bytes in all Heaps/EdgeTransport
• Process/Private Bytes/EdgeTransport

These two values won't necessarily hover around each other, however if you are seing huge increases in the Private Bytes over the managed # Bytes in all Heaps then chances are there's a 3rd party agent loaded on the server that references unmanaged modules. Nearly all of EdgeTransport is written in managed code so it's fairly rare to find a leak in EdgeTransport that isn't reflected in the managed heaps.

If you do see that, take a look at what agents are installed on the server with the Get-TransportAgent and/or Get-TransportPipeline cmdlets. Uninstall or at minimum, disable any 3rd party agents with Disable-TransportAgent AgentIdentity and restart the Microsoft Exchange Transport Service and monitor for leaks.

We determine a connecting client IP to be discredited if it has previously connected and disconnected under a tarpitted session. If it's discredited we pro-actively enable tarpitting, a process where we wait for a specific interval between ALL responses sent back to the client. The default for this interval is 5 seconds. Except under this condition, tarpitting usually occurs after the first command that results in an error response.

I've seen this bite in two ways:

1. Abitrary tweaking of the tarpitinterval and specifying a much longer interval than normal.
2. Servers that perform chunking, sending small chunks of BDAT data and monitoring CHUNK acknowledgements.

When tweaking the interval, I personally don't suggest anthing much higher than 5 seconds which happens to be the default. To set the value you use the following cmd:

set-ReceiveConnector "Connector Name" -tarpitinterval 00:00:5

Tarpitting is generally used to slow down directory harvesting and impeded mass mailing. The thought is if it takes too long to perform the operation mailers will give up. Again, I recommend the default but if you feel the need to tweak it, don't set it to 00:05:00 (5 minutes) like I've seen it.

Another way this impacted us is through chunking. Chunking provides a method to submit multiple SMTP commands in succession without waiting for a response. This impacted one mailer submitting to us because the mailer was submitting larger messages in small chunks. The 5 second intervals caused a queue up of 2.6.0 CHUNK received OK, ### octets responses from Exchange. Every response took 5 seconds, and after 1 minute the mailer gave up waiting for the additional responses and disconnected. The reason for this is that we tarpit every BDAT response that isn't the last chunk (BDAT ### LAST).

The only way to resolve under this situation is to set the tarpitInterval to 00:00:00 or disable Chunking and BinaryMime on your receive connector.

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4c4bd2a3-5e50-42b0-8bbb-2cc9afe3216a#tm

Maximum message size limits in Exchange Server 2007 can be set in a number of places, such as on the TransportConfig object, or individual user mailboxes. This helps prevent clients from submitting messages that are too large. One caveat, however, is that older Outlook clients (Outlook 2003 SP1 and older) could still submit a message that was larger than the maximum message size, the store would identify that the message was too large and NDR it, attaching the original message to the NDR. There are work arounds for this, such as blocking older Outlook clients from being able to connect to the store, but this isn't always acceptable in some customer envrionments and isn't a full proof way to block this issue from happening. Any custom MAPI application (regardless of the version of MAPI being used) can completely ignore that a maximum message size is present and simply submit a large message.

The problem attaching the original message to an NDR is that if the message was REALLY large, Hub Transport would often go into Back Pressure attempting to process the NDR, take note that the Hub NEVER sees the originally submitted message, only the NDR. Additionally, if it took longer than 5 minutes for the Hub to process the message, the Mail Submission Service could notify another Hub to process the message, causing a bad cascading effect through the Site.

We introduced a change in the store behavior with RU8 that causes the store to skip attaching the original message to the NDR if the cause of the NDR was due to exceeding the maximum submission size. This will greatly reduce the chance that a Hub will go into back pressure due to an excessively large NDR, assuming you have reasonable message size limits to begin with.

Per RFC 2047, encoded words can be used within the subject headers of a message and indeed Exchange Server 2007 is no exception and does support this. In a MIME message an encoded subject may look something like this:

 Subject: =?ISO-8859-1?B?VGhpcyBpcyBhIHRlc3Q=?=

The first part, ISO-8859-1, indicates the charset the subject is using, the B indicates that the remaining data is Base64 encoded and everything between the subsequent ? and ?= is the Base64 encoded subject. Quoted Printable is also supported and the same subject in quoted printable would appear as such:

Subject: =?ISO-8859-1?q?This=20is=20a=20test?=

What we ran into is that particularly long subjects were not being unencoded. As the message went through conversion we would truncate the subject to a maximum of 255 characters (while also appending "..."). What resulted was a rather unreadable subject in any client, whether it be Outlook, OWA, or your favorite POP/IMAP based reader. What we found is that, by default, Exchange Server 2007 will not attempt to decode any subject header that exceeds a total encoded length greater than 255 characters.

To resolve this you have to make the following changes on your Hub Servers (this has no affect on Edge):

1. In the \Exchange Server\Bin directory, open the EdgeTransport.Exe.Config file.
2. It should start with something that looks similar to:
   <configuration>
     <runtime>
       <gcServer enabled="false" />
     </runtime>
     <appSettings>
   ...and so on.
3. Add the following lines between the <configuration> and <runtime> elements:
   <configSections>
     <section name="CTS"
   type="Microsoft.Exchange.Data.Internal.CtsConfigurationSection, Microsoft.Exchange.Data.Common, PublicKeyToken=31bf3856ad364e35, version=8.0.681.0,
   culture=neutral"/>
   </configSections>
   <CTS>
     <MimeLimits>
       <MaximumEncodedWordLength Value="512"/>
     </MimeLimits>
   </CTS>
   
4. Save and exit the .config file. 
5. Restart the MSExchangeTransport service.
6. Resubmit your message and confirm the fix is working

Note: Step 3. The version does not need to be change based on the version of Exchange (E2K7 SP1, SP1 RU7, etc,.) that you have installed.

Base64 and Quoted-Printable encoding is going to introduce some additional bloat to the subject length so whatever value you set in the MaximumEncodedWordLength will need to support your maximum encoded values. 

Please note: No matter how long of a subject you submit, Exchange will ultimately truncate the unencoded version of that subject down to 255 characters and append "...".