Hello,

Just installed 2013 excahnge server 3 days ago. We noticed after the first night that we did not receive any external emails throughout the night.  I could not find anything wrong with receive connectors.  Telnet works internally when this happens but NO access from public side testing with telnet.  After I reboot the exchange server everything functions just fine and normal for about 8 hours until it happens again.

I dont know what to check or look for at this point.  Very new to exchange 2013.  Any kind of advice would be helpful at this time.

It is not a firewall issue.  Same firewall and set of rules that we use for other/old mail servers.  We only have 1 exchange server that has all roles.

Check the event logs for any issues

How is the behaviour in owa

Check all the exchange server services.

Check the event logs for any issues

How is the behaviour in owa

Check all the exchange server ser

It just happened again and Restarting the Microsoft Exchange Transport service gets it working again like restarting the server. At least we know what service to restart instead of rebooting the server. Now I can just restart the service every 4-8 hours instead. :(  I will look for

I will make a wild guess, could AV be causing Microsoft Exchange Transport services to stop ? can you disable AV to see if that makes a difference 

--ocd

AV has not been installed.

Right now I have a Powershell task that runs every 4 hours and restarts the transport service.  If I cant find an answer soon we will be calling Microsoft to try and figure this out.

The transport service never stops... It is still running but restarting the transport service resolves the issue of not collecting mail until we can figure out what the real problem is.  I am sure it is not good practice to be restarting the service every 4 hours.

Thanks for you input.

Hi,

same problem here. In the meantime we have no AV installed. All services are running, restarting the transport service resolves the issue. We installed all Microsoft updates.

BR

Stephan

Hi,

same problem here. In the meantime we have no AV installed. All services are running, restarting the transport service resolves the issue. We installed all Microsoft updates.

BR

Stephan

• Proposed as answer by Paul Loughran Friday, July 26, 2013 4:30 PM

Hi,

same problem here. In the meantime we have no AV installed. All services are running, restarting the transport service resolves the issue. We installed all Microsoft updates.

BR

Stephan

Hi Stephan

Please post back if you find a solution to this most irritating issue. I will do the same when and if I find a resolution.

Thanks

I have been having exactly the same issue's for over 2 weeks although it seems to sometimes work for up to 2 days before the incoming emails stop!, i thought it was something i had caused!, i had a suspicion it was something to do with the Windows Backup since it is taking an image of the server each time along with the exchange data, plus there is a new service which is installed when you install the Windows backup role, its called 'Microsoft Exchange Server Extension for windows server backup".... at first i thought the incoming emails would stop during or after a backup but i have managed now to get backups completing successfully and then today the emails stopped again. I do not have an AV installed, i think there is something wrong with the transport service! MS need to fix this urgently...

@Lead_Pusher

How did you setup the powershell task?

Nickyp103 

Create a powershell file with extension .ps1 and have the command "Restart-Service MsExchangeTransport" in the file then use Task Scheduler to run the command as often as you need it to run. 

Nickyp103 

Create a powershell file with extension .ps1 and have the command "Restart-Service MsExchangeTransport" in the file then use Task Scheduler to run the command as often as you need it to run. 

 

Does this server have more than one NIC?

I started a case today with Microsoft and this seems to be a known issue. The tech I was talking with said he has experienced this exact same thing with colleagues.  We went over alot of my config then he gathered a ton of log files and now I wait.  The tech support said they are working with the exchange team to find out why and a solution to the issue.

I have noticed that I am needing to restart the transport service about every 2.5 - 3.5 hours.  Hoping to get some results soon and will post results.

Thanks

Quick update

I have received a couple of kind emails since the original support ticket was created. Basically saying they are working on it and will get back to me as soon as they have a cure.

Also experiencing the same issue on a clean install of Exchange 2013 on a clean install of Windows Server 2012. The connectors being used are all the connectors that were created by default. No external AV software being used yet so that's not the issue. The issue starts anywhere from a few hours to a day after Exchange starts. I have been rebooting daily but will just restart the Transport Service since someone suggested that restores functionality. The mail is not being accepted by the server while the issue is occurring so some mail is returned non-deliverable if I don't restart Exchange soon enough.

Hope this is resolved ASAP.

Quick update

I have received a couple of kind emails since the original support ticket was created. Basically saying they are working on it and will get back to me as soon as they have a cure.

an update from me.

After i changed the DNS settings on the network adaptor to the server ip i.e 10.77.100.2 instead of 127.0.0.1 and also made sure the DNS reverse look up zone was setup correctly using the wizard i have not had the problem, emails have been flowing in perfectly for over 2 days! i am not sure if the issue has gone away but it seems to be more stable! lets see, ill post back if anything happens.

my setup is one server with the following roles installed (including Exchange 2013)

AD DS, APP SERVER, DHCP, DNS, FILE AND STORAGE SERVICES, IIS, REMOTE ACCESS plus Windows server back up.

an update from me.

After i changed the DNS settings on the network adaptor to the server ip i.e 10.77.100.2 instead of 127.0.0.1 and also made sure the DNS reverse look up zone was setup correctly using the wizard i have not had the problem, emails have been flowing in perfectly for over 2 days! i am not sure if the issue has gone away but it seems to be more stable! lets see, ill post back if anything happens.

my setup is one server with the following roles installed (including Exchange 2013)

AD DS, APP SERVER, DHCP, DNS, FILE AND STORAGE SERVICES, IIS, REMOTE ACCESS plus Windows server back up.

• Edited by bluelights Thursday, December 20, 2012 2:06 PM

I just collected another 2 gigs of dump files for the Microsoft support techs to study.  Hope something good comes out of this soon.

I hope something is resolved soon. Restarting services every few hours - on a brand new product that was a clean install - is extremely frustrating and bad for business - for Microsoft and for partners that promote the upgrade of products.

So far - between this issue and the removal of many management features from the administration interface - I am disappointed with Exchange 2013 versus Exchange 2010.

This problem is getting worse and worse, i am having to restart the transport service every 4 hours!

@Lead_Pusher

Is your Exchange 2013 on and DC the same machine?

No official news from any tech support cases or from the Exchange team? If so - that's very disappointing that such a significant issue for multiple organizations is not being resolved immediately.

I'm moving back to Exchange 2010 because I can't keep restarting server EVERY 4 HOURS and the Transport Service won't restart properly.

My Exchange 2013 is (soon to be was) on its own Server 2012 Std virtual server that is not a DC. Exchange 2013 is the only role for that server.

This problem is getting worse and worse, i am having to restart the transport service every 4 hours!

@Lead_Pusher

Is your Exchange 2013 on and DC the same machine?

Our Exchange Server is only an Exchange server , no other services and it is not a DC.  And we also restart the transport service every 3 hours.

@Lead_Pusher

Have you heard anything back about a fix yet? can you post back when you do?

Thanks

@Lead_Pusher

Have you heard anything back about a fix yet? can you post back when you do?

I am also having the same trouble for over a month now. Sometimes the mail server makes it several days before needing to be rebooted. I am unable to restart the transport service when the problem happens, it just hangs on restarting the service. 

I am running exchange on a VM server 2012. There are two nic cards installed, one is disabled within Windows Server. Syncing and sending e-mails still works fine when the problem happens. I have looked in the logs and see nothing obvious. Everything else on the server still works fine including IIS and Remote Desktop.

I have some semi Good news.  Our exchange has been working correctly for over 3 days now.  The Microsoft techs wanted to test by disabling the Receive connector I had created.  It was only for internal mail testing to make sure and allow anything in our internal development network the ability to send mail through our exchange server.  It was set up the exact same way we used it in exchange 2007 and 2010.  Something is definetly buggy about having to disable this receive connector.  Since that was really about the only thing we had done to our exchange install that was not DEFAULT that is why they wanted to disable.  Very strange since so many techs had looked at it and just dismissed it since it is NOT something that is so out of the ordinary.  Supposed to get a call back today sometime to go over the logs from the weekend.  This is still not solved but maybe for our Exchange server we are getting closer.

Anyone else with custom recieve connectors may want to consider disabling as a test to see if it helps or not.

That is all the info I have for now.

I dont have any additional receive connectors setup, i just have the standard ones from install, i made a small change to some of the settings but thats it!, i am not really seeing a pattern, sometimes the server is fine for a day other times i have to restart the transport service every few hours, i fear this will not be a quick fix!!! i think i will wait another week or so then switch back to Exchange 2010!

I am having the exact same problem. I think it has to do with backpressure. However there is no guidance out there on what settings to use for exchange 2013.

Also, what the hell is with these exchange diagnostics logs being generated in \Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics\DailyPerformanceLogs

these are HUGE and filling up my C: drive...

By the way... another sign Exchange 2013 was rushed out the door.

If you cant keep something as fundamental as an SMTP relay running on your server, it's flawed. Wake up MS and fix this.

I am having the same issues here with clean install win 2012 and virtual 2012 running 2013. I noticed something that may be related: 2010 Outlook cannot find a password once the transport problem starts.  In addition, my internal DNS goes haywire - I cannot find my 2012 DC under it's name, but I can connect under it's static IP. When I try to connect using the name, it pops out of remote desktop with a "this is not the server you were looking for" error. If I ping the name, it shows the same IP address as the mail server! Which, with a static Ip, should not be possible.

When I review DNS on the DC, all is as it should be. Tried the ipconfig/dnsflush on the client and no help - still messed up IP.

Reboot only the mail server and all is right with the world - for a few hours anyway.  DNS is not installed on the virtual mail server -so how does it get control of the DNS requests?

Update: DNS issue was a hyperV setting - it seems it is entirely possible and a default setting to have the management operating system and the guest use the same NIC even though you told it not to in the NIC setting directly. Stupid me,not looking through EVERY setting possible.

My transport will not stop in many cases, so I'm rebooting ona  daily or more basis.

I am having the same issues here with clean install win 2012 and virtual 2012 running 2013. I noticed something that may be related: 2010 Outlook cannot find a password once the transport problem starts.  In addition, my internal DNS goes haywire - I cannot find my 2012 DC under it's name, but I can connect under it's static IP. When I try to connect using the name, it pops out of remote desktop with a "this is not the server you were looking for" error. If I ping the name, it shows the same IP address as the mail server! Which, with a static Ip, should not be possible.

When I review DNS on the DC, all is as it should be. Tried the ipconfig/dnsflush on the client and no help - still messed up IP.

Reboot only the mail server and all is right with the world - for a few hours anyway.  DNS is not installed on the virtual mail server -so how does it get control of the DNS requests?

Update: DNS issue was a hyperV setting - it seems it is entirely possible and a default setting to have the management operating system and the guest use the same NIC even though you told it not to in the NIC setting directly. Stupid me,not looking through EVERY setting possible.

My transport will not stop in many cases, so I'm rebooting ona  daily or more basis.

• Edited by BJGINC Friday, January 04, 2013 4:27 PM

I've had EX2013 running for 3 weeks without a hitch and now suffering the same issue as you guys for the last 3 days - restarting the transport service every 4-8 hours...!

Could this have anything to do with WSUS, which I added to our network around a week ago?

I've had EX2013 running for 3 weeks without a hitch and now suffering the same issue as you guys for the last 3 days - restarting the transport service every 4-8 hours...!

Could this have anything to do with WSUS, which I added to our network around a week ago?

• Edited by gjross Saturday, January 05, 2013 6:47 AM

I've had EX2013 running for 3 weeks without a hitch and now suffering the same issue as you guys for the last 3 days - restarting the transport service every 4-8 hours...!

Could this have anything to do with WSUS, which I added to our network around a week ago?

No it cannot be anything to do with WSUS because i dont have it installed as a role on our server!

what i did do a few days ago is clean up the database's, i had created a new database and moved all the mailbox's to it, but the old one would not delete because it said it was still in use, i then used some commands to move the discovery mailbox along with all the arbitrations to the new database, this then completely emptied the original database and i was able to delete it and the rest of the logs/files, so lets see now how it goes, not sure if this is actually going to fix the issue but at least everything is now cleaned up.

I had setup a receive connector for SSRS to communicate with Exchange which this morning I disabled. Since then, mail flow has been absolutely fine, no transport restarts required at all, so I can only presume that the settings in the receive connector were causing the issue.

Could someone else try disabling any non-default connectors to see whether this works?

Okay, WSUS was a long shot but as I say, since I disabled my custom receive connector, this problem has not re-occurred.

Troy12n - have you modified any of the default connectors, in any way?

I am using just the default receive connectors and the problem is the same. I am running an experiment to see if the anti-malware filter is the cause after reviewing the logs  -  lots of anti-malware errors which, naturally, have no additional information available. I have bypassed the filter in the EMC.

The anti-spam agents have been: (1) not installed (same problem); (2)enabled (same problem); and (3) disabled (same problem). My users are not too happy about all the spam but they are understanding once I explain it's a Microsoft product.

So far its been 12 hours of uptime.  Will update as my experiment proceeds.

Update 1-8-13: System has been stable receiving emails for 24 hours. Lots of emails with both anti-spam and anti-malware turned off ;-)

Update 1-9-13: system up and stable for 48 hours. Logs lookk "normal".

Not positive, but it looks like the anti-malware agent is messing up the transport for me.

I am using just the default receive connectors and the problem is the same. I am running an experiment to see if the anti-malware filter is the cause after reviewing the logs  -  lots of anti-malware errors which, naturally, have no additional information available. I have bypassed the filter in the EMC.

The anti-spam agents have been: (1) not installed (same problem); (2)enabled (same problem); and (3) disabled (same problem). My users are not too happy about all the spam but they are understanding once I explain it's a Microsoft product.

So far its been 12 hours of uptime.  Will update as my experiment proceeds.

Update 1-8-13: System has been stable receiving emails for 24 hours. Lots of emails with both anti-spam and anti-malware turned off ;-)

Update 1-9-13: system up and stable for 48 hours. Logs lookk "normal".

Not positive, but it looks like the anti-malware agent is messing up the transport for me.

• Edited by BJGINC Wednesday, January 09, 2013 10:51 PM

Okay, WSUS was a long shot but as I say, since I disabled my custom receive connector, this problem has not re-occurred.

Troy12n - have you modified any of the default connectors, in any way?

Hi again,

Just got off the phone with Microsoft techs again.  They are able to reproduce the issue with custom receive connectors on an Exchange server that host CAS and Mailbox roles.  So an all in one Exchange server like my setup. The problem was with the New Custom Receive connector being associated with the HubTransport instead of the FrontendTransport  ??? So me and other users just following the same steps as they did in Exchange 2007 and 2010 would cause a problem. 

You can force the issue (replicate the problem) to occur faster if you shutdown the Microsoft Exchange Transport Service and Shutdown the Microsoft Exchange Frontend Transport Service... then start up the Microsoft Exchange Transport Service FIRST then start Frontend Service.  This will force the port 25 conflict that stops the external mail.

If you created a custom receive connector on Exchange and are experiencing issues delete that connector and recreate but this time choose Frontend instead of Hub for the role when creating it.

Shell command - New-Receiveconnector -Name <Name-It> -Usage Custom -Bindings 0.0.0.0:25 -RemoteIpRanges <xxx.xxx.xxx.xxx,etc> -TransportRole frontendtransport

OR the web interface

They told me that they will be releasing some notes on how to set the Receive Connectors up to clear up any confusion and at this point are not considering this a BUG in Exchange 2013.

I hope this helps some of you fix your Exchange servers from not excepting external email.

• Edited by gjross Wednesday, January 09, 2013 8:47 PM

My receive connector was to enable SQL database mail and SSRS to relay via exchange. I have set up a Frontend connector as suggested but neither database mail or SSRS will work - mailbox unavailable 5.7.1 unable to relay. With a hub transport connector, SQL mail and SSRS worked but of course the incoming mail stopped...!

Probably just need to tweak your permissions on the receive connector and make sure it has the correct IPs of the servers trying to send email.  This page should get you going http://exchangeserverpro.com/how-to-configure-a-relay-connector-for-exchange-server-2010 Its for 2010 but about the same process using the web interface.

• Edited by gjross Wednesday, January 09, 2013 11:03 PM
• Proposed as answer by Terence YuModerator Thursday, April 25, 2013 9:02 AM
• Unproposed as answer by Terence YuModerator Thursday, April 25, 2013 9:02 AM

I hope this helps some of you fix your Exchange servers from not excepting external email.

Hi again,

Just got off the phone with Microsoft techs again.  They are able to reproduce the issue with custom receive connectors on an Exchange server that host CAS and Mailbox roles.  So an all in one Exchange server like my setup. The problem was with the New Custom Receive connector being associated with the HubTransport instead of the FrontendTransport  ??? So me and other users just following the same steps as they did in Exchange 2007 and 2010 would cause a problem. 

You can force the issue (replicate the problem) to occur faster if you shutdown the Microsoft Exchange Transport Service and Shutdown the Microsoft Exchange Frontend Transport Service... then start up the Microsoft Exchange Transport Service FIRST then start Frontend Service.  This will force the port 25 conflict that stops the external mail.

If you created a custom receive connector on Exchange and are experiencing issues delete that connector and recreate but this time choose Frontend instead of Hub for the role when creating it.

Shell command - New-Receiveconnector -Name <Name-It> -Usage Custom -Bindings 0.0.0.0:25 -RemoteIpRanges <xxx.xxx.xxx.xxx,etc> -TransportRole frontendtransport

OR the web interface

They told me that they will be releasing some notes on how to set the Receive Connectors up to clear up any confusion and at this point are not considering this a BUG in Exchange 2013.

I hope this helps some of you fix your Exchange servers from not excepting external email.

@Lead Pusher

Did you see my screenshot above? these were all installed by default and i have not changed anything but still get the problem with mail stopping!!! im sure there is stil a bug

My install has been stable for a week after bypassing the anti malware filter 

Not sure if this is how it was applied but I am trying this method below. My install had no custom connectors setup either & the only changes made after the clean install were the steps published by MS to setup various incoming mail filters using the Exchange Powershell commands. This still wouldn't explain why it works fine for a short variable amount of time then stops accepting ANY e-mails.

http://technet.microsoft.com/en-us/library/jj150526(v=exchg.150).aspx

• Edited by BJGINC Monday, January 21, 2013 4:41 AM

FYI - our mail server has been running 6 days now without the mail rejection problems that were previously occurring every 4-24 hours for the last couple months. Bypassing the malware filter using the method below is what solved the problem for us.

We are still very disappointed that a brand new, clean install would've involved such a critical BUG that would cost a company SO much in labor costs (troubleshooting, loss of mail productivity & rebooting mail server FREQUENTLY) and it still has yet to be resolved officially by MS. Also disappointed with the change (lack of) in the management GUI related to SPAM and filters. So much for any ROI for the exciting new Exchange 2013.

http://technet.microsoft.com/en-us/library/jj150526(v=exchg.150).aspx

my receive connector was the default installed one which was front end transport anyway!

but since i temp disabled the malware filter it seems more stable as well, almost 3 days now with good mail flow, i will monitor further and see.

OK... Did alot of testing and spent some time with Microsoft's support on the phone.

I believe there is actually two problems going on in this thread.

1. Exchange 2013 Admins that have changed the default receive connectors are experiencing a conflict on the scope settings. Make sure that none of the receive connectors are using the same ports, and that you have not modified the security settings in anyway unless you really know what you are doing.

If you are unsure of what the settings should be after you have change them, the only suggestion I have right now, (as I have not taken the time to do screen shots or write down all the default settings) is to install Exchange 2013 on a virtual machine and look at them, then change back the settings that do not match.

2. The Malware Agent has a flaw that is causing the the Microsoft Exchange Transport service to endlessly wait on the Malware Agent to process a message that it just can't handle. (Two reboots of the entire server may be needed to clear this, or sometimes you can get away with restarting the Microsoft Exchange EdgeSync service.)

The Microsoft technician had me perform a sequence of steps that highlighted this. To see if this is infact your problem you can perform the following steps.

A)  Once the Exchange server stops processing messages, figure out the rough time it stopped processing messages.

B)  Open the event viewer.

C)  Under "Windows Logs", right click "Application", select "Filter Current Log...", check "Warning" and "Error", then click "OK".

D) Scroll down the log to the rough time that your Exchange Server stopped processing messages. You are looking for a slew of errors about the same time from "MSExchange Extensibility" (1051), "MSExchange Transport" (9201), "MSExchange Transport" (9201), "MSExchange Extensibility" (1056), "MSExchangeTransport" (10003), and "MSExchange Common" (4999).

It is the "MSExchangeTransport" (10003) that I believe is the real problem. The Microsoft technician agreed. He did not want to spectulate as to exactly what was going on, but it seems to me that since he had me disable the "Malware Agent" for now, that it is indeed the problem. 

E) So.... Open the Exchange Management Console and type "Disable-TransportAgent", followed by enter. It will prompt "Supply values for the following parameters:". Enter "Malware Agent", press enter again. Type "A", for yes to all.

or

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

F) Go to run, enter "services.msc". On the window that opens, find "Micorosoft Exchange Transport" and restart it.

I know this is NOT a fix, but a work around that is less than desired as the Malware Agent is a filter to keep unwanted emails out. I highly recommend running some sort of 3rd party spam/Malware filter that has been fully tested to run with Exchange 2013 if you do this.

Microsoft is to contact me back once they can figure out why this is happening, and I believe in the end a patch for Exchange 2013 will be produce to correct the problem.

In the mean time.... don't waste your money on paying Micorosoft for support, as I have already done this.

For the individuals who say they are not experiencing trouble, I am going to go out on a limb here and say that either you have a 3rd party software program that is filtering the mail before it reaches the Malware Agent, you have disabled the Malware Agent, or you are using another mail server to forward email to your Exchange 2013 server. With either of these cases you are much less likely to see this problem.

One last issue that a few people may be experiencing, is Exchange 2013, running on Server 2012 that is a VM. Several VM setups have a bug with the VM NIC management interface and Windows Server if you are using the same NIC for both. For example Xen Server 5.6 and XEN XCP both have this bug. There is an patch for XEN Server 5.6, but so far nothing for Xen XCP.

I have spent many hours trying to figure my problems with Exchange 2013 and I will not swear that my entire post is correct, but I have gotten very much closer to a stable mail server after much work. If you feel that anything is incorrect, please reply back and let me know why, so that we may all benifit.

P.S. Sorry for the mis-spellings and what not, I am very tired at the moment, and was forced to use explorer, because this site is not liking Chrome at the moment. (Will not let me login)

OK... Did alot of testing and spent some time with Microsoft's support on the phone.

I believe there is actually two problems going on in this thread.

1. Exchange 2013 Admins that have changed the default receive connectors are experiencing a conflict on the scope settings. Make sure that none of the receive connectors are using the same ports, and that you have not modified the security settings in anyway unless you really know what you are doing.

If you are unsure of what the settings should be after you have change them, the only suggestion I have right now, (as I have not taken the time to do screen shots or write down all the default settings) is to install Exchange 2013 on a virtual machine and look at them, then change back the settings that do not match.

2. The Malware Agent has a flaw that is causing the the Microsoft Exchange Transport service to endlessly wait on the Malware Agent to process a message that it just can't handle. (Two reboots of the entire server may be needed to clear this, or sometimes you can get away with restarting the Microsoft Exchange EdgeSync service.)

The Microsoft technician had me perform a sequence of steps that highlighted this. To see if this is infact your problem you can perform the following steps.

A)  Once the Exchange server stops processing messages, figure out the rough time it stopped processing messages.

B)  Open the event viewer.

C)  Under "Windows Logs", right click "Application", select "Filter Current Log...", check "Warning" and "Error", then click "OK".

D) Scroll down the log to the rough time that your Exchange Server stopped processing messages. You are looking for a slew of errors about the same time from "MSExchange Extensibility" (1051), "MSExchange Transport" (9201), "MSExchange Transport" (9201), "MSExchange Extensibility" (1056), "MSExchangeTransport" (10003), and "MSExchange Common" (4999).

It is the "MSExchangeTransport" (10003) that I believe is the real problem. The Microsoft technician agreed. He did not want to spectulate as to exactly what was going on, but it seems to me that since he had me disable the "Malware Agent" for now, that it is indeed the problem. 

E) So.... Open the Exchange Management Console and type "Disable-TransportAgent", followed by enter. It will prompt "Supply values for the following parameters:". Enter "Malware Agent", press enter again. Type "A", for yes to all.

or

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

F) Go to run, enter "services.msc". On the window that opens, find "Micorosoft Exchange Transport" and restart it.

I know this is NOT a fix, but a work around that is less than desired as the Malware Agent is a filter to keep unwanted emails out. I highly recommend running some sort of 3rd party spam/Malware filter that has been fully tested to run with Exchange 2013 if you do this.

Microsoft is to contact me back once they can figure out why this is happening, and I believe in the end a patch for Exchange 2013 will be produce to correct the problem.

In the mean time.... don't waste your money on paying Micorosoft for support, as I have already done this.

For the individuals who say they are not experiencing trouble, I am going to go out on a limb here and say that either you have a 3rd party software program that is filtering the mail before it reaches the Malware Agent, you have disabled the Malware Agent, or you are using another mail server to forward email to your Exchange 2013 server. With either of these cases you are much less likely to see this problem.

One last issue that a few people may be experiencing, is Exchange 2013, running on Server 2012 that is a VM. Several VM setups have a bug with the VM NIC management interface and Windows Server if you are using the same NIC for both. For example Xen Server 5.6 and XEN XCP both have this bug. There is an patch for XEN Server 5.6, but so far nothing for Xen XCP.

I have spent many hours trying to figure my problems with Exchange 2013 and I will not swear that my entire post is correct, but I have gotten very much closer to a stable mail server after much work. If you feel that anything is incorrect, please reply back and let me know why, so that we may all benifit.

P.S. Sorry for the mis-spellings and what not, I am very tired at the moment, and was forced to use explorer, because this site is not liking Chrome at the moment. (Will not let me login)

• Edited by Colin Slaughter Tuesday, January 29, 2013 7:06 AM
• Proposed as answer by Terence YuModerator Thursday, April 25, 2013 9:03 AM

Sorry, but anyone that jumps on the new software bandwagon without first testing to see if it meets their requirements . . .   --- Rich Matheisen MCSE+I, Exchange MVP  

MCSE? MVP? People like you are the reason I never bothered with such exams. Accusing somebody of poor planning by using RELEASE software is making excuses for Microsoft that you ought not to be making. This is a well developed and mature product put out by one of the largest software companies in the world. Such obvious and glaring errors should not exist and sure as hell shouldn't be defended by somebody like you.

The GUI (non-GUI) in this version is a joke. The first time in my life I've ever used Firefox was on my Exchange server because straight out of the box, IE10 would crash while managing my server. No spam filter or blacklist settings? The whole layout of the management frontend has changed without any fundamental shifts in the backend to necessitate it.

This isn't some stupid little open source project for an Android phone, THIS IS MICROSOFT EFFING EXCHANGE!!!!! Stop making excuses for these smacks.

hi there!

have exactly the same problems (described it here: http://social.technet.microsoft.com/Forums/en-US/exchangesvrsecuremessaging/thread/d696e5d9-fd5b-4511-8072-266315313de7) ... anyway, deleting the self-defined receive-connector, which was an hint in this thread, on my new server keeps it up & alive for 1 day right now - will look forward & keep on reporting here!

cheers

Since around January 15th when I disabled the built-in malware processing using the steps below, Exchange has been delivering mail without any restart. Prior to that, we were restarting the Exchange server (clean install) about every 4-24 hours for a couple months. We had no custom connectors - only the pre-installed connectors.

My feedback/complaints are that this release software probably shouldn't have been released with such a significant problem but then there were official tech support requests made and no real solutions other than what we figured out in trial & error. My install was a clean install on a clean install of Windows Server 2012, which is what I would expect MS wants me to pitch as a partner. I still have yet to see any official release of this being an issue and how customers can resolve it - or a patch that resolves it for the customer.

The GUI feedback I suggested is just that - feedback. It is disappointing to us that the management of the new built-in anti-malware, spam filters & other filters aren't able to be managed outside of PowerShell. It seems to be a part of the MS push of customers toward the hosted Exchange, which is a great solution but isn't for all industries/clients. Removing GUI/web management of features is a step backwards for many Exchange management users - some people love PowerShell & are fast with it but not everyone.

UPDATE: I thought all was good after disabling the malware filter however the transport service has once again hung and could not be restarted, so a full server reboot was required before email flow started to work again!

This is crazy, i think i will hold out for the CU1 update but if it continues then back to Exchange 2010 for me.

Same with one of our installations as well - we restart the transport service every 2 hours through a scheduled task... With our own installation we have no problems like that - running like a charm. Must be a specific problem in some envinronments...

Hope for a solution from Microsoft - hopefully with CU1. Further it would be great, if MS can provide more detailled information, whether this bug is addressed with CU1 and when it would be released...

Hi again,

Well the malware agent has struck our system too.  What is the solution?  If the agent is disabled mail flow works fine but the amount of spam is overwhelming.  If the agent is enabled then spam stops but so does the mail flow.  It seems that the agent takes forever or hangs up processing the mail.

Just got off phone with Exchange support and the Malware Agent issue is a known BUG. It is expected to be resolved in CU1 which i was told hopefully would be released in 4-6 weeks.  Look for and error with event ID 10003 in the application logs.  At least that is what i was told to look for and I had a bunch of them.  Work around for us is to bypass the malware agent. 

Exchange management shell - Set-MalwareFilteringServer -BypassFiltering $true and you can check the settings with Get-MalwareFilterServer | fl to see all the parameters for it.

Hope this helps

I m having the same problem... We have Exchange server 2003 installed. It stops working on every 12th day. Outlook shows msg REQUESTING DATA FROM SERVER and doesnt download new emails. but all clients are able to send email to outside and inside. Every time I have to restart the server. After restarting the server exchange works fine and all clients recieve emails in outlook. what is the cause ?? Every 12th day it happens from the date of restarting the server.

This one is killing me. MS, please fix it!

For me, the service will not restart on its own. I have to use "kill" to get it to shut down.

Any suggestions?

We had similar issues at a customer, which was unsupported to begin with btw. They had a SBS 2003 server (exchange 2003 thus) was hoping to migrate that to 2013 directly. Well apparently there's no migration path at all (unless you consider dumping everything to PST and importing it again a migration path - I call it crap (nice going btw MS)).

So I installed 2008 R2/Exchange 2010 trial, migrated everything there, removed exchange 2003, installed exchange 2013 on windows 2012 and migrated again. So far so good.

But then ran into this issue.

It turns out the installation had a 'Internal Relay' connector (Hub Transport) which probably originates from the 2003 server (I never created it on 2013 nor 2010 anyways) that was only set for the .2 IP in the subnet there (so the database server could send out e-mail w/o authenticating). Just removed that and re-enabled the malware filter (disabled it after reading here it would help - it did not :)).

Anyways, so far it's been stable for ~36 hours now.

Just FYI - HTH.

Anybody thought about disabling this to see if that would help?

http://technet.microsoft.com/en-us/library/bb201658(v=exchg.150).aspx

Since I have Exhange running in a Hyper-V virtual machine with only 2.5GB RAM (but only a few mailboxes) I disabled Back Pressure, but it didn't help.

The thing that worked for me (any many others) was to delete my custom receive connector and recreate it with Frontend transport.

I'm running Exch2013 in an Exch2010 environment, moved all mailboxes and everything works fine now, despite the lack of Exch2013 CU1...

Since I have Exhange running in a Hyper-V virtual machine with only 2.5GB RAM (but only a few mailboxes) I disabled Back Pressure, but it didn't help.

The thing that worked for me (any many others) was to delete my custom receive connector and recreate it with Frontend transport.

I'm running Exch2013 in an Exch2010 environment, moved all mailboxes and everything works fine now, despite the lack of Exch2013 CU1...

• Edited by Roger, Devrope Tuesday, March 26, 2013 7:39 PM

I called MS support and they got on my server and disabled the Malware Agent. Since then, it has been running smoothly.

They did check my receive connectors and said they looked good before they addressed the Malware Agent. They are planning an update soon.

I had the same problem, after 8~10 hours the smtp connection from public side went down. Telnet could connect internally but not from public side. The problem origin was the remote access server, I uninstalled it and installed again, reconfigured it and now everything works good.

I had the same problem. i opened an incident with Microsoft. What the tech did to resolve the problem was add my ip in the hosts file. After he did this, everything started working just fine.

hosts file is in c:\windows\system32\drivers\etc

he appended:

<ipaddress> <servername>
<ipaddress> <FQDN>

for example:

192.168.1.10 felix
192.168.1.10 felix.acme.local

Hope this helps.

I had the same problem. i opened an incident with Microsoft. What the tech did to resolve the problem was add my ip in the hosts file. After he did this, everything started working just fine.

hosts file is in c:\windows\system32\drivers\etc

he appended:

<ipaddress> <servername>
<ipaddress> <FQDN>

for example:

192.168.1.10 felix
192.168.1.10 felix.acme.local

Hope this helps.

• Proposed as answer by ANexus115 Saturday, April 27, 2013 11:19 PM

Hi JPeebles1434,

I just tried your solution, but after doing it a ping still returned the IPv6 Address of the server. I'm assuming that Microsoft requested you add the IPv4 address to force traffic through IPv4, but I fail to see what that would do if a simple ping would still go via IPv6. 

I have since discovered Windows 8 and 2012 both prefer IPv6 over IPv4 

SOO, my question. 

1) is your Exchange server running on Server 2012?

2) If you ping your servername from the server does it return the IPv4 address or the IPv6?

Thanks!

Hi cookmi1,

Try to stop the remote access service (vpn) before restart exchange transport service.

This not resolve this issue but not need to reboot your server.

Hi cookmi1,

Try to stop the remote access service (vpn) before restart exchange transport service.

This not resolve this issue but not need to reboot your server.

• Proposed as answer by Manoj-Kumar Tuesday, April 30, 2013 9:10 AM
• Unproposed as answer by Manoj-Kumar Tuesday, April 30, 2013 9:10 AM

Hi JPeebles1434,
after added the ip in the host file the problem was gone away. Great!

I had the same problem. i opened an incident with Microsoft. What the tech did to resolve the problem was add my ip in the hosts file. After he did this, everything started working just fine.

hosts file is in c:\windows\system32\drivers\etc

he appended:

<ipaddress> <servername>
<ipaddress> <FQDN>

for example:

192.168.1.10 felix
192.168.1.10 felix.acme.local

Hope this helps.

Thank you, I have the same problem and this proposition had fix my problem.

I had the same problem. i opened an incident with Microsoft. What the tech did to resolve the problem was add my ip in the hosts file. After he did this, everything started working just fine.

hosts file is in c:\windows\system32\drivers\etc

he appended:

<ipaddress> <servername>
<ipaddress> <FQDN>

for example:

192.168.1.10 felix
192.168.1.10 felix.acme.local

Hope this helps.

Thank you, I have the same problem and this proposition had fix my problem.

• Proposed as answer by api4all Saturday, May 25, 2013 11:57 AM

We have had the same issue whereby at random intervals (around 8 hours apart but not always) email functionality will stop working and we receive the following symptoms:

1.emails will get stuck in outbox in outlook

2.emails will get stuck in drafts in OWA

3.Emails cannot be received externally (They bounce back to the sender)

4.if you telnet in to the system from remote, you get a service temporarily unavailable error.

5.If you try to restart the transport service, it gets stuck stopping.

I have tried the following, and confirm none of the below prevented the issue from re-occurring:

1.I have a custom receive connector (for receiving scan to email messages from photocopier), I set this to frontend, and this did not solve the problem.

2.I have disabled the malware filter and this did not solve the problem.

I manage to temporarily resolve the problem by the following procedure:

1.Stop the routing and remote access service

2.restart the exchange transport service

3.restart the routing and remote access service.

Because of the above procedure, I have a feeling that maybe it is routing and remote access causing the problem (as mentioned above) and possibly the server trying to listen on the IP assigned to the server for routing and remote access??

Today I have implemented the suggested fix above regarding the adding of static DNS entries for the server name and server FQDN in hosts file.

I will report back if this resolves the issue.

Additional info:

Windows server 2012 with Exchange 2013 with CAS and Mailbox roles.

Brand new build.

only 1 custom receive connector.

• Proposed as answer by Nate_MCT Thursday, May 09, 2013 2:28 PM
• Unproposed as answer by Nate_MCT Thursday, May 09, 2013 2:29 PM

Put the local host's (Exchange server) IP address into the Internal Relay receive connector and restart the FrontEnd Transport service.

I don't know WHY it worked, but it did for me.  It was a "Try it and see what happens" stab in the dark.

I don't know how long it will last before I have to restart the FrontEnd Transport service again.

Put the local host's (Exchange server) IP address into the Internal Relay receive connector and restart the FrontEnd Transport service.

I don't know WHY it worked, but it did for me.  It was a "Try it and see what happens" stab in the dark.

I don't know how long it will last before I have to restart the FrontEnd Transport service again.

• Edited by Nate_MCT Thursday, May 09, 2013 2:33 PM

I had been battling this since day 1 of install.  And it seems to give results.

Setup: Single server with Active Directory, Routing and Remote Service, File and printing service, Exchange 2013.

For the first couple of weeks, I had to reboot almost everyday, because I could not restart the Transport Service.  The memory consumption goes to close to 100%, but strange enough, there is hardly load.  But anyhow... mails are not delivering internally nor externally.

Now, it has been running stable with mails flowing fine for 3 weeks.

Here is what I did:

* Disabled malware filter. 
* Set the IP of my host and FQDN in hosts file.
 10.0.0.2 myserver myserver.mydomain.com

* Delete custom Receive Connector that I have created as Hub Transport, re-created it as Front End transport (I set this with no encryption and no autnentication/anonymous access for internal scanning/fax delivery).

* I do have anti-spam configured for sender filtering, content-filtering, etc.

And... everything seems to run fine now.  I do think that my last change, re-creating the custom Receive Connector as Front End transport was the one that stopped all of this madness.

I hope that helps.

Andy

I had been battling this since day 1 of install.  And it seems to give results.

Setup: Single server with Active Directory, Routing and Remote Service, File and printing service, Exchange 2013.

For the first couple of weeks, I had to reboot almost everyday, because I could not restart the Transport Service.  The memory consumption goes to close to 100%, but strange enough, there is hardly load.  But anyhow... mails are not delivering internally nor externally.

Now, it has been running stable with mails flowing fine for 3 weeks.

Here is what I did:

* Disabled malware filter. 
* Set the IP of my host and FQDN in hosts file.
 10.0.0.2 myserver myserver.mydomain.com

* Delete custom Receive Connector that I have created as Hub Transport, re-created it as Front End transport (I set this with no encryption and no autnentication/anonymous access for internal scanning/fax delivery).

* I do have anti-spam configured for sender filtering, content-filtering, etc.

And... everything seems to run fine now.  I do think that my last change, re-creating the custom Receive Connector as Front End transport was the one that stopped all of this madness.

I hope that helps.

Andy

• Proposed as answer by api4all Saturday, May 25, 2013 11:58 AM
• Edited by Andy Cool Monday, June 10, 2013 6:39 AM

I solved the problem with reinstall the server with

Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms

http://technet.microsoft.com/en-us/library/dd876880%28v=exchg.150%29.aspx

Same issue also occurred to SMTP traffic from Ex2007 to 2013 SMTP after creating a custom hub connector. I've now removed the hub connector and thing are working well. I think this really is a bug.

When mail stop flowing in, I could send out.

Internal mail worked perfect.

I noticed my network card goes to limited - reinstall my nic but after 20 hours my nic goes back to limited

So what i did was change my receive connector to frontend transport - Still same problem

As soon as i entered the hosts as suggested above  - my nic started working perfect

Everything worked fine &  mail dropped in. i didnt even reboot my exchange transport service.

I do have dns records for my exchange but it doesnt make sense why i need to define it in my host

• Edited by TGH TGH Wednesday, August 21, 2013 10:12 AM

I still had acouple of issues from the above post with limited nic.

What made my exchange server perfect was Cumulative update 1 & 2

I really strongly suggest you apply both these updates - Done magic for me

Thanks everyone for there input - I finally have my email server back.

• Edited by TGH TGH Friday, August 23, 2013 8:00 PM

Hello,

I had two problems: 1 was the relay service would go into Guru meditation. It would not stop or crash, but e-mails stopped relaying.

The second was the same problem with RPC. Outlook client would disconnect and start prompting for passwords. Restarting the services helped but I was unable to isolate the problem exactly.

After installing CU1, both problems disappeared.

EXCHANGE 2010 TOO !  and a Diagnostic Clue

I have the same problem for about three weeks (since August 1, 2013)  It would run for about 20 hours before incoming email would not show up.   By trial and error, I also figured out restarting the Transport Service would restore service.

A Clue . . .   When its in this fail condition, it will still accept messages sent from foreign systems that use a local mailbox account as the sender.   ( I have security sytem at another location that sends various logs ever day using a local email address as the sender from the remote unrelated system) These message come through when foreign email addresses will not. 

so it has something to do with local domain address email being accepted from an external server and outside domains not being accepted.

Anyone figured out the real cause of this issue because now my server is also haunted it seems, I noticed these issues I believe right after a custom receive connector was install for our faxmaker server. Will try to remove it and see if issues get resolved.

My horror story :

http://social.technet.microsoft.com/Forums/exchange/en-US/50c9b523-fc98-4f11-995b-19d4a5ddcbbc/exchange-2013-unable-to-receieve-emails-when-dcs-are-rebooted

Have the same problem on one boxed DC2012R2/Exchange 2013CU2 Clean install!

Sometimes a "double restart" of server is needed to "releases" the mails in and out..

Added the ip with servername and FQDN i host file now and restarted the transport service and suddenly a lot of missing mails showed up, ..will see for how long :-/

• Edited by Kenneth Hemstad Thursday, September 05, 2013 4:57 PM

Wow CU2 also has similar issues ? When will MS fix these bugs completely ? By the time all bugs are fixed they will release probably exchange 2017 !

Out of curiosity do you have custom receive connectors on your exchange ?

This issue with the receive connectors is not really a bug, but a default behavior with Exchange 2013. So if you are planning to create additional receive connectors listening on port 25, it has to be assigned to the Frontend Transport role.

-PSS

  Sorry, but anyone that jumps on the new software bandwagon without first testing to see if it meets their requirements . . .   --- Rich Matheisen MCSE+I, Exchange MVP &n

Thanks to everybody for your posts. In one of my posts I incorrectly stated that the problem had gone away with CU1 update. It did not, the problem returned although it ran for 2 days after CU1. I also tried CU2 and that just made a train wreck of the EX server. I had to recover from a snapshot then I reinstalled CU2 (same exact steps) and this time it worked fine (go figure) but the main problem still has not gone away even with CU2.

I have what I believe are two separate problems. Both appear to be intermittent and I cannot isolate the cause.

The first is that the NIC icon shown limited connection and I lose all Exchange connectivity. Mail flow stops completely and Outlook connections are severed.

The second problem is that Outlook intermittently disconnects and prompts for a password although Active Synch devices can still send and receive fine.

I had become busy with a project but now I am back and will look into some of the fixes posted here. Thank you all for sharing. If I have any luck I will post back.

In addition, after tinkering around some more with it, I found that there is not RBL support (really?) and you need to get into PowerShell to configure the SPAM filter settings which is a bit of a pain. Amazingly, I too am using Firefox to manage Exchange 2013 ECP and Webmail because because it works better than IE10.

It appears that Exchange 2013 is an unfinished product and should be looked at and considered carefully before being considered before being installed in a production environment at this

For what it's worth I was getting this on my Exchange 2010 server just now.

Issue:

Lack of disk space.

There is an error event in the application event log saying that Transport will refuse new mail due to lack of disk space:

I have the same problem with a new exchange server - smtp stops accepting mails after minutes to hours.

i tried a lot and found out, that it does not happen if i delete my internal relay connector for my printers (scan to mail). since i deleted this connector, the problem does no occure anymore (one day till now...).

i'll update you if it keeps ok or not. maybe some of you have such an internal connector as well.

Are most people just setting up a scheduled task to restart the service?  What seems to be the magic timeframe?

I doubt it and I think one should not have to to restart, i think its the whole thing about custom relay's etc.

• Proposed as answer by TBone1985 Friday, October 11, 2013 4:22 PM

MrPKiAm

I agree we shouldn't have to restart, but from what I read in this feed, you have to delete the custom relay unless I'm missing something.  I have to have it for copiers/scanners to send via email.

• Edited by TBone1985 Thursday, October 10, 2013 8:00 PM

in the meantime i created a new internal receive connector but i've choosen a front end instead of hub. it works so far - i dont have problems untill now. before i made these changes the smtp service stopped at least once per hour. try it out....

Just wanted to throw in my 2 cents. I am currently working on migrating from Exchange 2007 to 2013, currently have coexistence up to the point of using 2013 for all client access, but all mailboxes and mail transport is still handled by the 2007. I had migrated a test account to the new sever earlier in the process and found that it could send and receive mail fine, however after just getting the 2013 server handling all client access and doing it's proxying thing, I noticed that the test account on the new server wasn't able to receive mail....the messages were stuck in the queue on the old server with the "Service not available" error message.

So I began to look into what could be causing it, and found all these posts about people experiencing receive connector issues after certain periods of activity. I decided I wouldn't restart the server or any services (As the server isn't live yet for anything but proxying/relaying client access) and try to investigate the problem more directly. What that led me to was the network adapter bindings for my receive connectors, which reminded me, this 2013 server, like the 2007 server, has 2 nics (The second handles iscsi for storage nodes). So I checked the bind order (network connections>alt-n>advanced>advanced settings) and sure enough, the iscsi storage nic was first. So I moved it down, letting the correct nic be first.  I then proceeded to tighten up the bindings on all my receive connectors to only look at the correct nic, and to ignore the iscsi nic, which took me about 5 minutes, and by the time I was done, I noticed the test messages that were queued for delivery from the 2007 server to the test mailbox on the 2013 server had arrived...about 5 minutes previous...the exact time I had changed the bind order in the advanced network connections.

So, I will be keeping an eye on it.  It's possible changing the bind order was no better than resetting the transport service, and it will eventually fail again, but I thought I would throw that out there as a possible helpful piece of info.

• Edited by bmathison Friday, October 25, 2013 3:12 PM typos

@ bmathison

Looks like in your case it was simple a mis-configured network port :p.

For those who are still experiencing this problem I will be working with MS on this today and will keep you updated. I cannot believe this problem is ongoing for nearly a year now.

What I have done so far:

1. Applied CU2
2. Disabled Anti-Malware Scanning (& $env:ExchangeInstallPath\Scripts\Disable-Antimalwarescanning.ps1)
3. Added server IP / FQDN in the hosts file 

The above three did not resolve this problem so in the meantime I have created a scheduled task to keep restarting the Ms Exchange Transport Service after every one hour (Restart-Service MsExchangeTransport)

Will touch base after MS come in to assist....

• Edited by Johnny_Soares Wednesday, October 30, 2013 7:41 AM

I have a customer with Exchange 2010 running on SBS 2011 (Server 2008, basically), Symantec Enterprise Protection and Symantec Email Protection, experiencing the problem of external email delivery stopping multiple times daily.  It just started happening about 10 days ago after the server had run OK for more than a year-and-a-half.  So far, they have just rebooted their server every time.  I will check the possible solutions listed here, but wanted to post so I receive email notification regarding any further posts.  Thanks,

Hi Johnny

We are having the same issue.

Any update on this.

Hello,

Just an update. I have been 3 weeks without a restart. For me it was allocating more RAM to the VM that ran Exchange 2013. It seems it had too little RAM allocated to it and was either paging or freezing the SMTP and RPC services. The added RAM fixed things up for me.

Had the same issue in a migration scenario from Exchange 2007 to 2013.

A colleague pointed me in the direction of receive connectors, and it turns out that if you have an internal receive connector based on a multi role server, the connector must have the FrontendTransport role. If you created a custom receive connector(ex for internal SMTP relaying) and the role is HubTransport, it messes up with all the other default connectors.

Solution:
Delete the misconfigured connector and recreate with the right parameters. Everything seems to work fine.

I have a customer with Exchange 2010 running on SBS 2011 (Server 2008, basically), Symantec Enterprise Protection and Symantec Email Protection, experiencing the problem of external email delivery stopping multiple times daily.  It just started happening about 10 days ago after the server had run OK for more than a year-and-a-half.  So far, they have just rebooted their server every time.  I will check the possible solutions listed here, but wanted to post so I receive email notification regarding any further posts.  Thanks,

thanks for this thread.

I ran in to the same issue when setting up a new receive connector to allow for internal relaying.

In exchange 2007 and 2010 this would be a hub transport connector.

Got to love how Microsoft just changes things with a new version rather than being consistent.

Reconfiguring it to not be hub transport connector fixed the issue.

Had the same issue in a migration scenario from Exchange 2007 to 2013.

A colleague pointed me in the direction of receive connectors, and it turns out that if you have an internal receive connector based on a multi role server, the connector must have the FrontendTransport role. If you created a custom receive connector(ex for internal SMTP relaying) and the role is HubTransport, it messes up with all the other default connectors.

Solution:
Delete the misconfigured connector and recreate with the right parameters. Everything seems to work

Rich - was that statement supposed to be a helpful? 

It wasn't...

I have never seen ANY small to medium-sized business that even REMOTELY has the resources to TEST a new version of Exchange Server.

In my case, a client's old SBS Server 2003 crashed, and needed to be replaced... NOW!

Why would anyone, ever, assume that the newest version of Exchange 2013 - that comes built-into Server 2012 standard, would not work out of the box, and needed to be "tested"?

------

I have been working with SBS 2003/2008/2011 for YEARS; the recent deployment I did of a Server 2012 Standard system was the most problematic server experience I have EVER had.

... and the Metro interface does NOT belong on a Server. PERIOD.

Quite seriously, if I had to do it all over again, I'd install SBS 2011 instead.

dear all friend my exchange server in Vm and 16gb ram and my externall mail not send &receive until restart transport and i install 16 gb ram in my server work fine in 3day no problem

This is a well known bug, and Lead Pusher has already explained perfectly well when you hit it and how to resolve this issue.

You hit the bug when you:

1. Have a multirole CAS/MBX Exchange 2013 server
2. Create a custom HUB transport connector

That's it!!!

Delete the custom HUB transport connector and recreate it as a FrontEnd one.

• Edited by NetoMeter Screencasts Wednesday, December 25, 2013 10:33 PM

Excellent!!!!!!!Solved!!!!!!!!!!!!!!!Incoming mail issue!!!!!!!!!!!!

My one is single Server exchange 2013 in win 2012 with all roles+AD

hosts file is in c:\windows\system32\drivers\etc

just appended:

<ipaddress> <servername>
<ipaddress> <FQDN>

for example:

192.168.1.10 felix
192.168.1.10 felix.acme.local

Thanks guys!!!!!!!!!!

• Edited by karzon007 Friday, January 24, 2014 12:08 PM

Hi,

Hi,

I have had the same issue but after extensive searching it looks as though I have something that works without the need to restart the transport service.

If you check your settings of your transport connectors by typing the following

get-transportservice |fl

get-frontendtransportservice |fl

You will find that both or just the frontendtransportservice does not have an ip in the internalDNS and externalDNS settings.

Set these to have the ip address that you use for DNS resolution in your domain and it will most likely fix your issue.

Thanks to this article for the suggestion. ://social.technet.microsoft.com/Forums/exchange/en-US/be568eab-45c1-4648-88df-99f4939dd845/mailflow-broken-error-451-470 (couldn't add a link because my account is not verified but just put http in front.

Things are looking promising for me at the moment.

After making these changes I restarted the transport service one last time.

• Edited by maddog56 Monday, February 03, 2014 3:01 AM
• Proposed as answer by El Taco Loco Monday, February 03, 2014 5:33 AM

Glad it worked for somebody but found overnight that the issue is still there.

I am going to install CU3 and see if that fixes it.

Hi

i've the same problem, have you solved with the 'update?

Hi,

This problem Exchange 2013: SMTP 421 4.3.2 Service not active  can because of an update on the Exchange server and also if you tried to install EX2013 sp1 and cancelled it...

Check the ServerComponentState (Get-ServerComponentState -id ServerName) and see if the Component is "inactive" to set them all active run this command:
Set-ServerComponentState -id ServerName -State Active -Requester Functional -Component ServerWideOffline
After that check (Get-ServerComponentState -id ServerName) they should all be Active or the ones there have "work" to do like HubTransport and FrontendTransport.

Hope this helps out there

/Soeren

I fixed mine with this,

http://exchangemaster.wordpress.com/2014/01/24/incorrectly-adding-new-receive-connector-breaks-exchange-2013-transport/

• Proposed as answer by bwolter Monday, May 12, 2014 7:35 PM

I wanted to stop in here since there were so many folks with this issue. After all of these attempts here, I managed to figure out what was stopping mail flow. There is a resource monitor in Exchange 2013 that will actually stop mail flow if it notices some resources are getting close to 100% or if other resource usage is just too high. If they are too high, the service will slow down or "tarpit" mail delivery. If the severity reaches "high" mail flow will stop altogether. Restarting the transport service fixes this issue, but eventually (sometimes it was a few days for me, other times a few hours) the resources will shut down again.

I wrote a full article and fix and explanation here:

http://danblee.com/exchange-2013-mail-stuck-in-outbox-or-drafts-have-to-restart-transport-service-to-resume-mail-flow/

You can also see the technet article explaining exactly what's going on here:

http://technet.microsoft.com/en-us/library/bb201658%28v=exchg.150%29.aspx

Please let me know if this fixes your issue. I'm hoping it helps many!

• Proposed as answer by Henrik O. Skogmo Tuesday, December 30, 2014 8:52 AM

I too started experienced this problem as of late. First I didn't it could be that it went into back pressure mode, since the mailboxes were stored on the E-drive which had plenty of spare space. However the mail queue was operating of the C-drive, which was running low on available space.

I discovered this through the event viewer:

And followed the following steps to move the mail queue from the C-drive to the E-drive:

http://technet.microsoft.com/en-us/library/bb125177%28v=exchg.150%29.aspx

• Edited by Henrik O. Skogmo Tuesday, December 30, 2014 9:05 AM link
• Proposed as answer by Henrik O. Skogmo Tuesday, December 30, 2014 9:06 AM