Link to home
Start Free TrialLog in
Avatar of mltets
mltetsFlag for United States of America

asked on

Can't send email internally to mail enabled public folder on exchange 2007 SP3

I've got a strange one for you.  
Exchange (ent) 2007 SP3 - single server running windows 2008.  
The problem is with mail enabled public folders.  External email (smtp) from the internet works fine.  
Email created internally, via direct smtp address or via address book fails to work.  It queues up on the server and isn't delivered.  
Direct posts to the public folders work as well.

Permissions are fine (external email works).  
Everything looks to be configured correctly.  Hub transport config looks alright.  Mailboxes work fine.  I've been hunting for a solution to this all day.  Most everything I've found simply points to folder permissions which I've verified.  Replication and Exchange system objects look fine too.

We've called Microsoft and they seem to be at a loss.  I'm expecting a call from them in the morning.  I've scheduled a reboot of the server for later tonight (just in case it fixes it, even though I doubt it will).  

If you can help me fix this before they get back to me, in addition to the 500 points, you'll have bragging rights.

Naturally, this is time sensitive and somewhat critical as we use public folders for a lot of internal mail.
Avatar of mass2612
mass2612
Flag of Australia image

Hi,

Do you have any errors or logs being generated? Have you turned up diagnostic logging? MS are very good especially if you upload the MPS_REPORTS to them. They have scripts that run through the stuff and can find very obscure settings that are outside the normal range.

Diagnostic Logging of Exchange Processes
http://technet.microsoft.com/en-us/library/bb201668(EXCHG.80).aspx
Avatar of mltets

ASKER

I'll take a look.  Not sure how adept I would be at deciphering much of the logging though.
If you see anything worth posting blank out names, etc and post the details - maybe it will help. Also remember to revert the settings when you are done otherwise the logging can slow things down a little.
Avatar of mltets

ASKER

There are an awful lot of options in there.  It's not really generating an error though.  Just a failure to connect.

The message we receive 4 hours after attempting to send is:
Delivery is delayed to these recipients or distribution lists:

Mail Enabled Public Folder Name

Subject: testat426

This message has not yet been delivered. Microsoft Exchange will continue to try delivering the message on your behalf.

Delivery of this message will be attempted until 2/11/2011 4:18:40 PM (GMT-06:00) Central Time (US & Canada). Microsoft Exchange will notify you if the message can't be delivered by that time
If you mail enable a new public folder do you get the same results? Can you create a new PF, mail enable it and test internally and externally?

Can you run from the EMS and post here for one of the PF's that's failing (you probably have already) : -

Get-MailPublicFolder -Identity "\PFName\PFName\" | fl



Avatar of mltets

ASKER

Thanks for working with me on this.  
I created one earlier today as is, but thought I'd run through the process again.
created folder - success
mail enabled - success
text external - fail
fixed stupid permissions - success
test external - success
test internal - fail

Here's the output from the get command


Contacts                           : {}
DeliverToMailboxAndForward         : False
ExternalEmailAddress               : expf:ISLAN2AA8907BF4D13762D105F6BB4AE4E219
                                     0BD3586
ForwardingAddress                  :
PublicFolderType                   : Mapi
PhoneticDisplayName                :
RootUrl                            :
AcceptMessagesOnlyFrom             : {}
AcceptMessagesOnlyFromDLMembers    : {}
AddressListMembership              : {Default Global Address List, Public Folde
                                     rs}
Alias                              : islan22
OrganizationalUnit                 : mlt.inc/Microsoft Exchange System Objects
CustomAttribute1                   :
CustomAttribute10                  :
CustomAttribute11                  :
CustomAttribute12                  :
CustomAttribute13                  :
CustomAttribute14                  :
CustomAttribute15                  :
CustomAttribute2                   :
CustomAttribute3                   :
CustomAttribute4                   :
CustomAttribute5                   :
CustomAttribute6                   :
CustomAttribute7                   :
CustomAttribute8                   :
CustomAttribute9                   :
DisplayName                        : islan2
EmailAddresses                     : {SMTP:is
                                     lan22@mltvacations.com, X400:C=US;A= ;P=ML
                                     TINC;O=Minnetonka;S=islan22;}
GrantSendOnBehalfTo                : {}
HiddenFromAddressListsEnabled      : False
LegacyExchangeDN                   : /O=MLTINC/OU=EXCHANGE ADMINISTRATIVE GROUP
                                      (FYDIBOHF23SPDLT)/CN=RECIPIENTS/CN=ISLAN2
                                     AA8907BF4D13762D105F6BB4AE4E2190BD3586
MaxSendSize                        : unlimited
MaxReceiveSize                     : unlimited
PoliciesIncluded                   : {{EF4A415F-E2BF-49FA-AA9E-C1AE9795080B},{2
                                     6491CFC-9E50-4857-861B-0CB8DF22B5D7}}
PoliciesExcluded                   : {}
EmailAddressPolicyEnabled          : True
PrimarySmtpAddress                 : islan22@mltvacations.com
RecipientType                      : PublicFolder
RecipientTypeDetails               : PublicFolder
RejectMessagesFrom                 : {}
RejectMessagesFromDLMembers        : {}
RequireSenderAuthenticationEnabled : False
SimpleDisplayName                  :
UMDtmfMap                          : {}
WindowsEmailAddress                : islan22@mltvacations.com
IsValid                            : True
OriginatingServer                  : hdqntadb.MLT.inc
ExchangeVersion                    : 0.0 (6.5.6500.0)
Name                               : islan2
DistinguishedName                  : CN=islan2,CN=Microsoft Exchange System Obj
                                     ects,DC=MLT,DC=inc
Identity                           : MLT.inc/Microsoft Exchange System Objects/
                                     islan2
Guid                               : a8f95a7b-e9ba-49cc-88b6-e29365b2877c
ObjectCategory                     : MLT.inc/Configuration/Schema/ms-Exch-Publi
                                     c-Folder
ObjectClass                        : {top, publicFolder}
WhenChanged                        : 2/9/2011 9:34:58 PM
WhenCreated                        : 2/9/2011 9:34:40 PM



 
ASKER CERTIFIED SOLUTION
Avatar of mass2612
mass2612
Flag of Australia image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of mltets

ASKER

the messages don't show up in the queues anywhere.  that's part of what's so aggravating about it.  they're just not there...  
Avatar of mltets

ASKER

I just sent a test message and it made it through.  I tried again and it didn't.  no idea why.  I'm certain it has something to do with the internal routing to get to the public folder store.  Replication on active directory checks out fine so no idea why my one test made it...  it still continues to fail.  I've been at this since about 8:00 this morning.  I'm going forward with the reboot later tonight and will have to tackle it again then.
oh... even stranger. Have to love these kind of issues. Have to have a think about it a bit more - let us know how you go.
Avatar of mltets

ASKER

Whatever happens,I'm posting the solution here.  No reason why anyone else should have to call microsoft to get something like this fixed.
Do you have an Exchange 2003 server anywhere?

Also confirm you are running Exchange 2007 SP3?

What happens if you send to the PF with OWA does it arrive?
Avatar of mltets

ASKER

I tried the email from OWA and it doesn't make it.  We did have exchange 2003 and migrated off of it.  I found one obscure reference to deleting the old empty CN=Servers with ADSIEdit.  I did that and it still didn't correct the problem.  We bounced the server last night and when we tested it worked.  but stopped working about 10 minutes later...  I'm almost convinced that it's a problem within AD having to do with the routing not getting the correct destination to route to but am having trouble nailing it down as everything looks alright.  

I did correct a domain replication issue earlier this week.  Found a pesky WINS issue with a non-disabled nic and extraneous ip's being registered, but it was working for days after I fixed that.  I checked the Exchange settings within AD on all of our DCs (all 6of them) and they look to be replicating fine so whatever our problem is, it shouldn't be becuase of disparate AD problems.

I'm waiting for MS to call me this morning.  
Avatar of mltets

ASKER

Kind of interesting...
I'm in ADSIEdit...
Under Configuration \ Services\ MS Exchange \ Our Org \ Administrative Groups
I see two trees... one for our old environment (Minnetonka) and one for CN=Exchange Administrtive Group

The CN=Folder Hierarchies exists under the old one (Minnetonka) but one doesn't exist under the newer Exchange Admin Group.  Is there supposed to be one here?  I have to admit, I haven't dug into exchange this deeply in the past.  One of those, 'hey,it always worked' sort of things.

Besides, we've seen it work a couple of times but then stop working so it makes the problem even wierder...  How would I track the routing process for mail created internally and routed to public folders, remembering that externally created SMTP mail is delivered fine (different path?)....
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of mltets

ASKER

It's all good....
Thanks for the answer.
Great and thanks for taking the time to post the solution.
Avatar of mltets

ASKER

It was looking at the queues...  on the backup DR server in the "other datacenter"... the one no one thinks of...