If you attempt to connect to and send mail via command line to your Exchange Server, you may see the following error after you end the data section of the operation.
451 4.7.0 Temporary server error. Please try again later. PRX5
Solution 451 4.7.1 Error
Log into Exchange Amin Center > Mail Flow > Receive Connectors > Default Frontend {Server-Name} > Edit > Scope > Select the IPV4 entry (Either Remove it and ad a new one or edit it)
Specify the IP address you want to use.
So, it should look like this > Save > Exit Exchange Management.
Open Notepad (Note: you need to run as administrator). Navigate to C:\Windows 32\Drivers\Etc locate the hosts file (If you can’t see it change the option to “All Files“
At the bottom of the file enter the IP hostname and FQDN of the server then save and exit.
Then restart the Exchange Transport Service.
Related Articles, References, Credits, or External Links
I see various posts in online forums, and the process is held up because a lot of techs can’t do basic troubleshooting on their Exchange deployments. So I thought I’d put together some basic ‘first steps’ for you to do when your ‘Exchange Stopped Working‘
This way you can at least get an error code to search for or a better idea of what’s going on.
Exchange Stopped Working – First Steps
Well it is Microsoft, reboot it, (yes turn it off and turn it on again.) I myself have lost time troubleshooting a problem that would have been cured with a simple reboot!
Disk Space: Look at you drives, if you are low on space, databases will fail to mount and bad things will happen, If you’re not backing up and logs are not getting flushed, then drives will fill up. It takes two seconds to check.
Services: Next culprit, look for all the Exchange services that are set to ‘Automatic‘ and manually start them (some may start and stop and that’s OK), but if you get an error, then screenshot that error, look in event viewer and get a copy of the error/warning then you are armed with good internet searching ammunition!
Exchange Stopped Working – Are you Accepting SMTP?
The simplest test is to see if Exchange is actually providing main services (on TCP Port 25 (SMTP)). You can do this by (on the Exchange server).
[box]
telnet localhost 25
[/box]
And you should get a response (see below). If that fails, then the usual culprit, (if all the services are running), is AV software blocking port 25.
Exchange Stopped Working – Test Email from CLI (Telnet)
I consider this a basic Exchange Skill, (the ability to send an email from command line). You first need to Telnet to the server (as above) you can then send an email. WARNING if you make a mistake, or have a typo (even if you correct that typo, before hitting enter) it will error! If in doubt write all your commands in notepad and paste them in!
Commands to use;
ehlo {Enter}
This is an ‘Extended’ helo (yes that’s spelled correctly) it opens communications and the server should respond with a list of the services it offers.
Tech Note: Also a good way to see if TLS is supported (it should respond with 250-STARTTLS)
mail from: {email-address} {Enter}
This can be ‘any’ source email address, even one that does not exist.
rcpt to:{email-address} {Enter}
Needs to be an email address that this Exchange has a mailbox for (on a domain that it’s authoritative for).
data {Enter}
Then type some text, you can continue typing as much text as you like.
.{Enter}
That’s a full stop, (period for the US), followed by Enter.
Then, (assuming it was successful and said 250 2.6.0 mail queued for delivery). If not you have an error code to Google. Check the mail was received.
Exchange Stopped Working – Test ‘Inbound’ Mail flow.
If you got this far then internally things are looking healthy, you need to see if you can accept mail from ‘Outside’. Repeat the test you carried out above but for a machine on the public internet, telnet in to the public DNS name of your Exchange and send an email via command line.
This proves your DNS is correct*, your firewall is setup correctly, and your Exchange is receiving mail.
*Note: Assuming you connected to the DNS name, (if you connected to the public IP then your problem may be DNS!)
Exchange Stopped Working – Test ‘Outbound’ Mail flow.
This one is easy to troubleshoot, send an outbound mail.
Locate the Exchange Toolbox > Queue Viewer.
Look for mail ‘stuck‘ on the outbound queue, in production there will probably be hundreds of them, but what you are looking for is an error message. In the example below that’s 451 4.4.397 (Which I forced to happen by blocking outbound traffic from the Exchange server on the firewall). If you see this make sure the Exchange has TCP port 25 open outbound.
Now you have enough information to either get on the forums and search, or open a new question if your stuck (AND TRY SEARCHING THIS WEBSITE FOR THE ERROR (TOP RIGHT)). I’ve fixed a few!
Related Articles, References, Credits, or External Links
While testing mail flow on a new SBS 2011 Server, outbound mail worked fine, but no mail would flow in. When I attempted to Telnet in from a remote host this was what I saw;
421 4.3.2 Service not available
Connection to host lost.
Solution
Normally I’d expect to see an error like this if the Exchange ‘Receive Connector’ was misconfigured, (if you’re not using SBS 2011 create a new default receive connector and make sure there are no firewalls in the way).
If you are using SBS 2011 you need to run the ‘Connect to the Internet’ Wizard (seriously!)
After this check inbound mail flow again.
Related Articles, References, Credits, or External Links
You will see this error in one of two scenarios, firstly it’s a new Exchange Installation and you have yet to create a send connector, or your send connector(s) do not cover the DNS name of the recipient the message giving you the error was destined for.
Identity: DC2012Unreachable412316860424
Subject: inter domain
Internet Message ID: <afea4f1a2aa14c2788d872070ae6a5dd@DC2012.PNL.com>
From Address: Administrator@pnl.com
Status: Ready
Size (KB): 4
Message Source Name: SMTP:Default DC2012
Source IP: 192.168.1.0
SCL: -1
Date Received: 11/26/2012 2:04:33 PM
Expiration Time: 11/28/2012 2:04:33 PM
Last Error: A matching connector cannot be found to route the external recipient
Queue ID: DC2012Unreachable
Recipients: name@domain-name.com;2;2;A matching connector cannot be found to route the external recipient;16;<No Matching Connector>
Usually you will have a send connector that covers “*” (that’s everything) so you either need to create that or a connector specifically for this problem domain name.
Solution
1. Launch the Exchange Admin Center https://localhost/ecp > Mail Flow > Send Connector > Click the Add icon.
2. Give it a sensible name and set it’s type to Internet.
3. By default it will select where to send the email based on the DNS name of the recipient, however some people route all their mail via a smart host, (this can be a server or IP address at your ISP or a mail filtering provider). If you use a smart host you will probably already know, in most cases you will want the default option of ‘MX record associated with recipient domain’ > Next.
4. Select the Add Icon > To create a ‘Default Send Connector’ that will cover ALL external domains, then set the FQDN to an asterisk, (for a domain specific connector simply enter the FQDN for that domain). > Save > Next.
5. Add > Now select the server(s) that will use the connector > OK > Finish.
Note: This is a great feature, if you have multiple sites, and multiple Exchange servers you can set the Exchange server at your main site as the default sending server. That’s great for solving mail flow problems caused by reverse DNS lookup failures.
6. At this point I’d either restart the Exchange services, or simply reboot the server.
Related Articles, References, Credits, or External Links
While putting in a New Exchange 2010 server today, I test moved a mailbox to this new site, and could not get mail to flow to the Exchange 2010 server at the clients main site.
451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host , but that did not succeed. Either there are no alternative hosts, or delivery failed to all alternative hosts.
Mail flowed from the main site to this new site, and internal mail at the new site was fine, but any mail destined for the main site, or going external (because the main site has the only server that can use the Exchange organization send connector) would fail with this error.
Solution
I did a lot of trawling to try and find the answer to this, and discovered lots of reasons for this to happen, so rather than just posting what fixed mine, from the most popular to the most obscure try these in order, and attempt to send mail after each step.
Note: Any change on an Exchange Server’s Receive Connectors should be followed by you restarting the Microsoft Exchange Transport Service (on the server you made the change on) before you try again.
1. On the server you are trying to send TO, check the properties of the Default receive connector and ensure ‘Exchange Server authentication’ is selected.
2. On the server you are trying to send TO, If you have a connector configured to ‘relay’ mail, make sure that the server(s) or network specified DOES NOT include the IP address of the server you cannot send FROM. Also Make sure on the authentication tab ‘Exchange Server authentication’ is NOT selected.
3. If you have Cisco PIX Firewalls between these two mail servers (running version 6 or earlier) make sure smtp fixup is disabled.
[box]
Petes-PIX>
Petes-PIX> enable
Password: *******
Petes-PIX# configure terminal
Petes-PIX(config)# no fixup protocol smtp 25
Petes-PIX(config)# write mem
Building configuration...
Cryptochecksum: f59a9bd3 3129b8bc 474b2415 52f2db0f
1049 bytes copied in 0.430 secs
[OK]
[/box]
4. If you have Cisco ASA Firewalls between these two mail servers, then remove esmtp from the default inspection map.
At this point I admitted defeat and picked up the phone and called Microsoft. One of their support engineers looked at the connectors and settings, and tested the DNS, had me create a new connector, still mail refused to flow. He did however get me pointed in the right direction. When attempting to Telnet to the Exchange server on the main site this is what we saw;
This is what we should be seeing;
Eureka!
I put all the firewalls in, so I know how they are configured, and I know this client has a CSC module in the ASA 5510 at the mail site, I managed to get the output above by rebooting that module, as soon as it was back online we reverted to the short list again. Also while the CSC was rebooting all the mails stuck on the outbound queue cleared.
Enabling CSC Bypass for a Remote Mail Server
Note: Your class-maps, and access-lists may have different names but this should point you in the right direction.
1. Connect to the ASA, view the policy-maps in use.
[box]
Petes-ASA# show run policy-map
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
inspect icmp
inspect pptp
inspect ip-options
class global-class <<<<< Here we go
csc fail-open <<<< This is the one we are looking for
!
Petes-ASA#
[/box]
2. We can see the class-map the CSC is using is called ‘global-class’, let’s take look at that.
[box]
Petes-ASA# show run class-map global-class
!
class-map global-class
match access-list global_mpc <<<<Here's how its being applied
!
[/box]
3. Now we know that’s being applied with an access-list called global_mpc, let’s see what that’s doing.
[box]
Petes-ASA# show run access-list global_mpc
access-list global_mpc extended deny ip host 10.1.0.253 any
access-list global_mpc extended permit tcp any any object-group DM_INLINE_TCP_1
Petes-ASA#
[/box]
Note: Remember permit means inspect and deny means don’t inspect, you can see mine’s set not to scan the CSC update traffic because that’s good practice;
4. So I just need to add in the IP of the Exchange server I cannot send from to make its traffic bypass the CSC Module. Remember to put it at the top so it gets processed before the permit or it will get ignored.
[box]
Petes-ASA# configure terminal
Petes-ASA(config)# access-list global_mpc line 1 extended deny ip host 10.3.0.2 any
My colleague Allen was doing an Exchange 2003 to 2010 migration today, and things were not going well, mail refused to flow from the Exchange 2003 server to the Exchange 2010 server (it flowed from 2010 to 2003 without error). During migrations that’s not unusual, and removing and recreating the routing groups usually fixes it, but he had done that. Mail was sat on the Exchange 2003 Server outbound queues on the queue that matched the routing group connector, but refused to move with the above error.
Solution
For about 45 minutes I was also scratching my head, but then I had a brainwave. If Exchange 2003 has a ‘Smart Host’ Configured on the ‘Default SMTP Virtual Server’ then it attempts to send traffic down the routing group via the smart host, (which will obviously fail). Remove any entry from the smart host section.
When done, restart the SMTP Service, and the Exchange Routing Service, and the queues should start to clear.
Related Articles, References, Credits, or External Links