Exchange 2013: inbound mail blijft in queue (event 1035)

[mvandek2]

Sinds gister blijft alle inkomende mail in de mailqueue hangen met melding:
441 4.4.1 Error encountered while communicating with primary target IP address: ""Failed to connect.

Ik zie verder ook event 1035 in de evenlog:
Inbound authentication failed with error LogonDenied for Receive connector Client Frontend <SERVERNAAM>. The authentication mechanism is Login. The source IP address of the client who tried to authenticate to Microsoft Exchange is [127.0.0.1].

Ik krijg enkel DNS als mogelijke oorzaak maar die staat keurig op het server IP, geen externe adressen of wat ook.
Uitgaand dus geen probleem, alleen alle inkomende mail komt in de queue, ook intern verzonden.

Iemand een idee?
Word zeer gewaardeerd!

[larshack]

Draaien al je services? Genoeg schijfruimte vrij op je C: schijf?

[mvandek2]

Outlook clients kunnen gewoon verbinden en mail verzenden, alleen komt er niets binnen.
Information store, transport, enz. draaien dus ook.

Schijfruimte was gisteren inderdaad te klein door teveel transaction logs; na een backup met VSS was dat opgeschoond en nu ruimte genoeg.

[larshack]

Hoeveel ruimte heb je nu op je C schijf?
Anders de server een keer herstarten. Ik had laatst hetzelfde probleem, maar dan met Exchange 2016.

[mvandek2]

150Gb, de totale DB is circa 30Gb. ik heb al 2x herstart.

Ik zie gisteren 14:06, nog voor ik ruimte ging maken en het nog werkte, ineens deze melding in C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\QueueViewer\TRANSPORTQUEUE20160821-1.LOG

2016-08-21T14:06:07.448Z,1,QUEUE,TDM-WIN2012\3,Retry,SmtpDeliveryToMailbox,mailbox database 0806615613,(mailbox database 0806615613)::0:13:5f0644:0::0:0:;,10,0,0,0,0,0,Internal,Normal,0,5f0644eb-7dce-40d1-b545-340aff318ceb,,"441 4.4.1 Error encountered while communicating with primary target IP address: ""Failed to connect. ",,

[larshack]

Dat zou genoeg moeten zijn inderdaad.

-Hangt er nog iets in de queue? (get-queue)
-Is er iets gewijzigd aan je infrastructuur?

[mvandek2]

Nee, verder niets gewijzigd.
Uitgaand geen probleem maar binnenkomend blijft allemaal hangen.

[larshack]

Krijg je een foutcode als je via telnet een test bericht stuurt?
https://technet.microsoft...aa995718(v=exchg.65).aspx

[RoelVB]

Staat IPv6 wel aan op de netwerkinterface van de server? Exchange kan hier weleens moeilijk over doen.

[Oogje]

ReceiveConnector gewijzigd gisteren?
Of een nieuwe connector toegevoegd die ook op poort 25 staat?

[ Voor 46% gewijzigd door Oogje op 30-08-2016 16:57 ]

[Question Mark]

mvandek2 schreef op maandag 22 augustus 2016 @ 14:44:

Inbound authentication failed with error LogonDenied for Receive connector Client Frontend <SERVERNAAM>. The authentication mechanism is Login. The source IP address of the client who tried to authenticate to Microsoft Exchange is [127.0.0.1].

Wat zijn de instellingen op deze connector?

[OK13]

Mogelijk de netwerken waar mail vandaan mag komen aangepast op de connector?

[mvandek2]

OK, enerzijds vervelend want had ik moeten zien en larshack zei het al maar anderszijds prettig want niets ingewikkelds aan de hand, oorzaak was dat de Mailbox Transport Delivery Service uit was.
Het zullen de steeds veranderende Windows services wel zijn.

Bedankt voor de input!

[mvandek2]

@larshack, https://technet.microsoft...b123686(v=exchg.160).aspx is een wat recentere versie van de telnet SMTP check.
Toch krijg ik hier eigenlijk nooit een positieve test mee op servers die prima draaien. Verbindingen worden voortijdig verbroken of 5.7.1. Unable to relay, dat laatste zal met instellingen te maken hebben maar toch is een goede testmethode wel erg handig.
Weet iemand een betrouwbare, werkende testroutine?

[Killah_Priest]

mvandek2 schreef op dinsdag 06 september 2016 @ 16:47:
@larshack, https://technet.microsoft...b123686(v=exchg.160).aspx is een wat recentere versie van de telnet SMTP check.
Toch krijg ik hier eigenlijk nooit een positieve test mee op servers die prima draaien. Verbindingen worden voortijdig verbroken of 5.7.1. Unable to relay, dat laatste zal met instellingen te maken hebben maar toch is een goede testmethode wel erg handig.
Weet iemand een betrouwbare, werkende testroutine?

Ik gebruik altijd Telnet of Send-MailMessage (Powershell).
Telnet blijft bij mij echter toch wel de voorkeur hebben, het is simpel maar zeer doeltreffend om te achterhalen waar het mis gaat.

[mvandek2]

Nog een vraag hierover, ik gebruik syntax zoals op http://exchange.sembee.info/network/openrelaytest.asp vanaf een Windows 10 pc (met telnet actief) maar krijg zodra ik het command "open <ip> 25" geef steeds:

421 4.3.2 Service not available

De verbinding met de host is verbroken.

Druk op een toets om verder te gaan...

[Oogje]

Heb je soms zelf een receive connector aangemaakt met Hub Tranport Role ipv Frontend?
Dan willen 2 services poort 25 claimen...dat gaat ergens na een tijdje fout en dan krijg je dit soort gedrag.

Als je de exchange transport services herstart en dan een telnet doet, werkt het dan wel?