What have I seen lately?

Journal Reports getting stuck in the submission queue

2009-01-30T02:23:00Z

We get lots of calls about Journal reports getting stuck in the submission queue. Generally when this happens it’s because of a configuration problem somewhere. If this is happening to you, start thinking about what tweaking you have done that weren’t suggested when reading the TechNet articles on journaling. Here are a few specifics that I have seen.

Scenario: You have both Exchange 2003 and Exchange 2007 mailboxes. Your journal mailbox is on Exchange 2007.

Answer: In a mixed mode environment, you need to have your journal mailbox on Exchange 2003.

Scenario: You are forwarding a copy of the journal report to an external smtp address.

Answer: This is fine to do, but please do it correctly. What is correct? Create an AD contact for the external smtp address and add this to the journal mailbox. (For an exchange 2007 mailbox: View properties of the mailbox, Mail Flow Settings Tab, Delivery Options Properties.) I have had customers do this with Outlook rules, or by modifying properties in AD with adsiedit. Both of these scenarios will result in messages sticking in the submission queue.

For general information on Journaling with Exchange 2007 see:
White Paper: Exchange 2007 Transport Journaling

http://technet.microsoft.com/en-us/library/bb738122.aspx

More Powerful Journaling in Exchange 2007

http://technet.microsoft.com/en-us/magazine/2006.12.journaling.aspx

Overview of journaling in Exchange 2007

http://msexchangeteam.com/archive/2007/06/22/444296.aspx

Understanding Journaling in a Mixed Exchange 2003 and Exchange 2007 Environment

http://technet.microsoft.com/en-us/library/aa997918.aspx

Exchange Management Pack & the "Exchange Transaction Log files are equal to or older than the maximum days allowed" rule

2008-11-08T02:57:00Z

By default this rule is set to check for any log files that are older than 2 days. Some customers like this rule, but want a larger window. So, let’s say you want MOM to notify you if there are any transaction log files older than 4 days. How do you do that?

Many people just change the "Max_Days_Old" parameter in the script, but this doesn’t get it.

You may also be tempted to make the change on the "Exchange Transaction Log files are equal to or older than the maximum days allowed" rule, but again, this is wrong.

Here is how to do this:

1. Go into the Administrator Console -> Rule Groups -> Microsoft Exchange Server -> Exchange 2003 -> Health Monitoring and Performance Thresholds -> Server Configuration and Security Monitoring -> Event Rules

2. Go to the rule named "Verify that the Log Files are being truncated by backup (by age modified)"

3. Open the properties of this rule

4. Click the Data Provider tab

a. Verify that it's using the default provider, which is a provider named "Exchange 20003-Schedule every 1 days synchronize at 04:01". That will cause the script to run once a day.

5. Click the Responses tab

a. Select the script and click Edit and change the value here.

6. Run the Commit Configuration Change command

a. In the Administrators Console, Right click “Management Packs”

b. Select Commit Configuration Change

Exchange 2007 journal reports and winmail.dat attachments

2008-10-09T23:34:00Z

I worked an issue today that I thought I would mention since there seems to be others out there with it.

Issue:

Journal Reports that were forwarded to an external smtp address were received with winmail.dat attachment.

Cause for this issue:

Exchange 2007 Journal Message Behavior for encoding:

- Messages sent to an internal journal recipient are TNEF encoded.

- Messages which are sent to an external SMTP address are still encoded like Exchange Server 2003 did them.

Exchange 2003 Journal Message Behavior for encoding:

- Only the attachments for the journal messages are TNEF encoded.

The content type is defined as multipart/mixed.

The message body is Content-Type: text/plain;

The attachment is encoded as Content-Type: application/ms-tnef; name="winmail.dat".

*By having Outlook forward the journal report to the external recipient, the message was then treated as any other external message instead of as a journal report.

Resolution:

1. Create a distribution list to journal to.

2. Add the journal mailbox as a member to that group.

3. Add a mail enabled contact (for the external recipient) as a member of the group.

4. Go to the properties of the database that you want to journal & add the distribution group as the journal recipient.

There have been quite a few changes in message journaling in Exchange 2007, you will want to read up on it. Here is a link to the whitepaper. http://technet.microsoft.com/en-us/library/bb738122.aspx

Need to convert Global groups to Universal groups? Do you have messages to global groups disappearing?

2008-08-04T19:58:00Z

I was working a case last week where my customer had messages to distribution groups disappearing. There were two parts of the answer to this one.

They were global groups. Even if we are hitting the issue in KB283051, it should be intermittent, but it was happening every time for this customer. Here is a summary of what is happening with these: With Global groups, the group will replicate to all GC's in the forest, but the group membership will only replicate to the local DC's. So, if for some reason Exchange can't contact the local GC you will see this issue. (General troubleshooting on this one would involve turning up diagnostic logging for dsaccess - topogy to medium & wait 15 minutes for the 2080 event and then check the event logs on any in site DC's that we aren't able to contact.)

After looking some more, we found that none of their exchange 2007 servers were seeing any local DC's. They were only seeing the root level DC's. This ended up being a problem with the group membership of the Exchange 2007 servers. They were not a member of the Exchange Servers Group with a default exchange 2007 security group. Once we added the Exchange 2007 server to the Exchange Servers group, the Exchange 2007 servers were able to discover the local DC's. (OK, we are half way there.)

So, once we got the exchange server to see local GC's, we expect the original issue to only be intermittent but we don't want it to ever happen. You can do this one of two ways:

1. Convert the global groups to universal

2. hard code the GC's that exchange will use (Please only do this as a temporary fix, not a permanent solution.)

We don't really recommend hard coding the GC's for various reasons, so then we look at converting the groups. This customer had thousands of them and manually doing this will be a mess. Luckily, you can do this with the Exchange Management Shell. Here is the syntax:

Get-DistributionGroup | where { $_.Grouptype -Like "Global*" } | Set-Group -Universal

Exchange 2007 HUB Transport service will not start

2008-07-10T17:27:00Z

We are seeing lots of this issue today after customers install security updates. You may also see these events in your applicatiopn log:

Event ID   : 7009
Type        : Error
Message  : Timeout (30000 milliseconds) waiting for the Microsoft Exchange Transport service to connect.

Event ID : 7000
Type : Error
Message : The Microsoft Exchange Transport service failed to start due to the following error: %%1053

We are seeing several different things resolve this one, depending on what else you are running on the box.

The quick & easy one that seems to work in all cases is to change the Transport Service to use the local system account. (NOTE: Please don't use this long term, just to get you up and running until we have a better answer.)

Other possibilities for resolution:

Read the article on our Exchange Team Blog: http://msexchangeteam.com/archive/2008/07/08/449159.aspx
Look at KB944752 and set the timeouts.
Remove RU3
Remove the other updates that were applied.
Look for event 4999 in the application log. It points to calculateTiServerRoutes. Do you have a 3rd party app that uses the same virtual server names as Exchange? For example; Legato CoStandby Server? If so,use adsiedit and check the attributes of the server. I suspect that you will see the same value for ncacn_p_tcp in the networkaddress attribute. This is the problem. One needs to be removed or changed.

I will keep updating this blog as we get new information on this one.

How to tell which Receive Connector is answering

2008-06-25T00:51:00Z

The simple answer is: modify the smtp banner so that you can see who responds.

On the server that you are connecting to:

Get-receiveconnectors
Look for the Identity field & note that.
Set-receiveconnector –identity “NameOfConnector” –banner “220 WhatEverYouWant”

Note: the banner has to start with 220<space>YourText. The 220 in the banner is the response code which lets the client know to continue the session.

Note: This changes the actual smtp banner for an smtp conversation. When you are done troubleshooting, you will want to remove this.

For example:
The Exchange server name we will use is: GCS3E2K7

Get-receiveconnectors
Look for the Identity field & note it for the connector that you want to change.
(The Identity of mine is: GCS3E2k7\Default GCSE2K7)
Set-receiveconnector –identity “GCS3E2K7\Default GCS3E2K7” –banner “220 My Default Connector”
Just to be careful, I want to check myself and verify that I set this correctly.
get-receiveconnector –identity “GCS3E2K7\Default GCS3E2K7” | *
Review the results. The banner field is not populated with “220 My Default Connector” so I'm good.
Next, telnet to that server and the banner will tell me if my default connector is the one answering the telnet session.
telnet GCS3E2K7 25 answers with a Banner of “220 My Default Connector.”

So, I know without a doubt that my default connector is the one answering my telnet request.

Why would you do this? I have a perfect example for you. My customer couldnt get mail flow to work from their Hub to their Edge Server. The telnet session failed with: 5.7.1 Unable to relay. We did all of the normal things that you check with an "Unable to relay" issue and none of that checked out. Finally, we altered the banner on his receive connectors on the Edge server and were able to determine that when he would make a connection from his Hub server to the Edge server it was being answered by the wrong connector.

SMTP Configuration - Unspecified Error

2008-06-12T20:55:00Z

UPDATED: The public hotfix is now available for this.

We are seeing a new issue where you are unable to configure the Access Tab of the SMTP Virtual Server. This happens on a server running SMTP and MOSS. Users are seeing this issue after applying Hotfix 946517.

SMTP still functions fine, the only issue is with making changes to the Access Tab of the SMTP virtual server.

The public hotfix is now available. See this article:

950426 You cannot apply the changes that you make on the Access tab of the properties page for an SMTP virtual server on a Windows Server 2003-based computer after you apply hotfix 946517

http://support.microsoft.com/default.aspx?scid=kb;EN-US;950426