2

I have a domain and wild card cert installed. Currently I can login to https://mail.advsystems.com/owa/

I can send mail internally and receive mail internally.

I can't receive mail from an external source. Example: [email protected] and [email protected] are able to send a recieve mail to each other.

I can send mail from Test2@advsystems to [email protected] but when I send it from [email protected] to Test2 it is never received.

When I try to make it a hybrid solution I get a HCW8078 error. https://i.stack.imgur.com/78nab.jpg

The Firewall is set to allow ports 25, 587, 80, and 443.

We have an MX, Host @, Points to Mail.Advsystems.com

We have a Autodiscovery, Host Autodiscover, Points to autodiscover.outlook.com

We have SRV, Service _autodiscover, Protocal _tcp, Name @, Target mail.advsystems.com

Citizen
  • 1,103
  • 1
  • 10
  • 19
Michael Downey
  • 37
  • 2
  • 12
  • 1) Show the complete error message (a screen shot) please. 2) Learn the error message first, and then you can move on to fix it. Don't start guessing what's up too early. – Lex Li Dec 20 '19 at 03:02
  • Why are you trying to create a hybrid? Are you going to migrate the mailboxes to Office 365? If not, then leave the hybrid alone. As to the actual issue, have you configured your network firewall correctly? Have you created DNS records for the name you're trying to connect to? Have you tested that https://localhost/owa works from the server itself? – joeqwerty Dec 21 '19 at 05:29
  • I currently have 365 as a temp solution. Once I get on Premise working I intend to drop the 365. – Michael Downey Dec 21 '19 at 05:34
  • Then you don't need a hybrid. Get the on premises Exchange working and then you can change your external MX and Autodiscover DNS records to pint to the on premises Exchange server. Did you check the items I listed in my previous comment? – joeqwerty Dec 21 '19 at 16:17
  • Firewall is Set to allow 25, 587, 80, and 443. We have an MX, Host @, Points to Mail.Advsystems.com, We have a Autodiscovery, Host Autodiscover, Points to autodiscover.outlook.com then an SRV, Service _autodiscover, Protocal _tcp, Name @, Target mail.advsystems.com – Michael Downey Dec 21 '19 at 16:37
  • `But I can't send or receive mail from the owa externally` - You need to give us more details. What does that mean exactly? What happens when you try to send email FROM your Exchange mailbox? What happens when you try to send email TO your Exchange mailbox? Telling us that you can't send or receive mail from the owa externally doesn't give us any useful information to help you. – joeqwerty Dec 21 '19 at 16:51
  • Typo when logging into https://mail.advsystems.com/owa/ with two accounts [email protected] and [email protected] I am able to send mail back and forth but when I try to mail it to say [email protected] I do not receive the mail. Also when I send mail from gmail to either test1 or test2 it fails. – Michael Downey Dec 21 '19 at 16:55
  • By using ECP, have you checked your (default) frontend transport connector to see if anonymous users can connect to it? Also make sure it allows all hosts to connect to it. While at it, also make sure your FQDN is set properly in the transport connectors that receive mail from the outside. – Miuku Dec 23 '19 at 09:13

2 Answers2

2

On ASI-EX01.advsystems.com (mail.advsystems.com) I can see this error:

451 4.7.0 Temporary server error. Please try again later. PRX2

PRX errors can have multiple causes. In most cases I have seen, I found somehow conflicting or wrongly configures Transport Agents and/or Connectors. But there are other reasons. This (most probably incomplete) list should be a good starting point for debugging:

  • Check your eventlog for erros from MSExchangeTransport with ID 7001. If you can se those, check the message for details. I have see crashing security tools (like AV), antispam-agents and defective ram. Check the Transport Agent(s) mentioned in the details pane (Get-TransportAgent) and disable the culprit.
  • If you are using the Default connector, set the logging level to 'verbose' and make DOUBLE sure, that anonymous users are allowed to use this connector ('anonymous' is NOT enabled by default).
  • Triple check your DNS settings on the exchange machine. This error appears, when the MTA is receiving conflicting answers (for example wrong MX data). I have seen this on slow (forwarder-to-forwarder-to-forwarder chains) DNS setups and on machines with more than one DNS server (eg AD DNS and some internet router/resolver). Exchange needs to be able to resolve itself with it's internal IP.
  • Open up ECP and go to "Server" -> "Server" -> "DNS-Lookups". Chose the correct NIC (the one with correct DNS settings) and/or try to add your preferred (and correctly configured) DNS here, manually.
  • Make sure, IPv6 is enabled and active on your NIC. IPv6 is a mandatory part of the Windows operating system (and exchange) and it is enabled and included in nearly all standard service and application testing during the operating system development process. Because Windows was designed specifically with IPv6 present, sometimes strange stuff happens when IPv6 is disabled or deactivated on a funtional (aka service'd) NIC.

After you did this, restart your transport agents (Restart-Service *transport*). If your PRX* errors persist, check the eventlogs. Most probably the culprit will leave some traces in the application event log.

bjoster
  • 4,805
  • 5
  • 25
  • 33
2

As Bjoster pointed to at the end, you're now to a point where logging becomes very important.

I just tried spinning an SMTP message to your test1@ account, and your server responded with a 250 (everything worked) message. Are you still having trouble receiving messages? If so, it is going to be something internal to your transport pipeline. The good news is that you can run tracing to see where messages are going now that they're being accepted by the MTA and into the transport.

You'll need to do the same basic thing with your outbound messages. Send one from your test account(s) to public and well-known mail systems (I'm a sucker for using Gmail and HoTMaiL for this, they both let you see the raw message with headers if needs be). Then in your Exchange system, run a trace to find the message and its handling events. You want to walk through each step of the pipeline and see where the final disposition went (did it get transfered to another server, did your server discard it for some reason, etc).

If the messages show as making it out of your system and into the recipient (Gmail, for example) then login to your account on that system and check all the spam/junk/rejection folders you have. It may be that the messages are delivered, but that spam protection is kicking in; you'll need to do a header analysis to see if that's the case. Most times when I hear "I just setup my new Exchange server but I can't send mail outside" it is really "My new server isn't identified in my SPF records, or isn't doing DKIM signing that I've enforced with DMARC; and because of that all my outgoing mail is being tossed as spam."

Ruscal
  • 1,223
  • 6
  • 14