Cannot send from accepted domain 550 5.7.1 Client does not have permissions to send as this sender
- I've been banging my head over this one all day today. I've got an Exchange 2007 Server Enterprise Edition setup as follows:
HUB1/Mailbox
HUB2/CAS
EdgeTransport1
EdgeTransport2
I have 6 domains on the accepted domains list Under the Exchange Organization Hub Transport settings like this:
domain-a.com Authoritative
domain-b.com Authoritative
domain-c.com Authoritative
domain-d.com Authoritative
domain-e.com Authoritative
domain-f.com Authoritative
I also have Email Address Policies setup for each of these domains all of which are applied except domain-d.com and domain-e.com (because these domains are depricated).
Here's the problem. I'm running some tests via POP/SMTP on the HUB2/CAS server. I have everything working just fine except for the fact that I cannot send from one of the accepted domains. I am able to change my e-mail address to appear as if I am coming from johnh@domain-a.com - johnh@domain-e.com (yes, even domain-d.com and domain-e.com which do not have applied email address policies), but I am unable to email from johnh@domain-f.com. My predecessor setup domain-a.com - domain-e.com. I setup domain-f.com. I'm wondering if I have done something incorrect that would not allow ANY user to send from that domain. I've tried granting my individual user ADPermissions on the receive connector with ExtendedRights ms-Exch-SMTP-Accept-Authoritative-Domain-Sender and have tried to grand these permissions to all Authenticated Users. This has not worked either time. Each time I make a change, I restart the Exchange Information Store (as recommended in other online blogs for speedy AD propagation of configs) and this does not work. This is only if I do it through POP/SMTP connections. If I set the "Set as Reply" address to johnh@domain-f.com and use Outlook to connect through Exchange itself, the test messages go through and appear to come from johnh@domain-f.com. Again, through POP/SMTP I always get 550 5.7.1 Client does not have permissions to send as this sender.
I'm going to go bald pulling my hair out over this one. Does anyone know what would cause me to not be able to send from this single domain. Is there a limitation to the number of accepted domains that Exchange 2007 Enterprise can handle? Is there some extra step that I'm missing here when adding an accepted domain?
Réponses
- Ok,
I'm marking this as answered. I'm not certain as to what was causing this or what fixed it. Perhaps it just took some time for our exchange organization to propagate the changes in the accepted domains. I'm not 100% sure. So my advice for anyone who comes across this is to restart all of your services on your hub transport servers (if you're using more than one hub transport server) and possibly reboot all the systems in the exchange organization after adding a new accepted domain. Make sure that you have applied e-mail address policies for all new accepted domais. If you are experiencing similar issues with "credentials not found" for your edge transport servers after adding a secondary/tertiary Hub transport server do the following:
If you have more than one edge transport server, do these one at a time to minimize downtime.
Remove the Edge subscription from one of the hub transport servers.
Restart the Trasport service on all hub transport servers.
Remove the Edge Subscription from the corresponding edge transport server with the "Remove-EdgeSubscription" cmdlet.
Restart the transport service on that edge transport server.
Create a new edge subscription with the "New-EdgeSubscription" cmdlet.
Move that subscription XML file to any of the Hub Transport servers (I prefer to do it on my hub transport that has the mailbox role as well but it should work from any hub transport server).
Add the new edge subscription with the EMC and allow it to create the send connectors.
Start the Edge sync process by running the "Start-EdgeSynchroniztion" cmdlet from the NEW hub transport server (do this to make sure that your new hub server doesn't throw any errors on syncing).
Lather, rinse, repeat for all other edge transport servers in your organization.
I hope this helps anyone else who is experiencing similar problems.- Marqué comme réponseJ Holmes lundi 30 novembre 2009 19:55
Toutes les réponses
Hi,
1. I suggest you create a new Receive Connector on the Hub Server and enable Exchange Users group to use the Receive Connector. Please also enable Basic Authentication on the new Receive Connector. After that, please check whether the issue persists by using the new Receive Connector.
2. Would you please let me know whether you created a new accepted domain domain-f.com and update current Email Address Policy to including the new email address or create new Email Address Policy? Please share detailed steps which you add the new domain that I can local test on my lab to reproduce the issue.
3. Would you please enable protocol logging on the Receive Connector and post related log when the issue occurs here?
~~~~~~~~~~~~~~~~Mike Shen
TechNet Subscriber Support in forum
If you have any feedback on our support, please contact tngfb@microsoft.com
~~~~~~~~~~~~~~~~
- Mike,
Thank you for you suggestion. All of the suggestions you offered were already done prior to my post. I did however find out what was causing it. I went through Event Logs and found that my second hub transport server (the role that was added to the CAS server after initial setup and after the original domains were added) was throwing Edge Sync errors. I copied the edge subscription files for my edge transport servers over from HUB1 to HUB2/CAS and within 2 hours the problem had corrected itself. I didn't realize that the second hub transport server needed the edge subscription files as I thought that was only needed one time on any hub transport server in the exchange organization. Apparently this is not so.
Thanks again,
John H - Ok Mike,
I suppose I was mistaken on what exactly happen. I can now say that I'm thoroughly confused as to how this matter was resolved. I took a look at my Hub2 server and found that the errors were still present. Perhaps it just took time for the accepted domain to propagate throughout the organization, I'm not certain. I guess I'll look into thoseNo credential was found for EdgeTransport1.mydomain.com and,
No credential was found for EdgeTransport2.mydomain.com
errors. Thanks for chiming in.
John H - Ok,
I'm marking this as answered. I'm not certain as to what was causing this or what fixed it. Perhaps it just took some time for our exchange organization to propagate the changes in the accepted domains. I'm not 100% sure. So my advice for anyone who comes across this is to restart all of your services on your hub transport servers (if you're using more than one hub transport server) and possibly reboot all the systems in the exchange organization after adding a new accepted domain. Make sure that you have applied e-mail address policies for all new accepted domais. If you are experiencing similar issues with "credentials not found" for your edge transport servers after adding a secondary/tertiary Hub transport server do the following:
If you have more than one edge transport server, do these one at a time to minimize downtime.
Remove the Edge subscription from one of the hub transport servers.
Restart the Trasport service on all hub transport servers.
Remove the Edge Subscription from the corresponding edge transport server with the "Remove-EdgeSubscription" cmdlet.
Restart the transport service on that edge transport server.
Create a new edge subscription with the "New-EdgeSubscription" cmdlet.
Move that subscription XML file to any of the Hub Transport servers (I prefer to do it on my hub transport that has the mailbox role as well but it should work from any hub transport server).
Add the new edge subscription with the EMC and allow it to create the send connectors.
Start the Edge sync process by running the "Start-EdgeSynchroniztion" cmdlet from the NEW hub transport server (do this to make sure that your new hub server doesn't throw any errors on syncing).
Lather, rinse, repeat for all other edge transport servers in your organization.
I hope this helps anyone else who is experiencing similar problems.- Marqué comme réponseJ Holmes lundi 30 novembre 2009 19:55