Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 256
  • Last Modified:

Could BES be the issue with my exchange server?

When moving to Exchange 2010, I also needed to move my BES server.

Part of the requirements for BES was to download and install http://www.microsoft.com/download/en/details.aspx?id=1004 on my Exchange Server.

I did this, and then later was told I shouldn't run the BES on the same machine as Exchange, so I created another virtual machine for BES. I have been having some issues with sending email on my exchange server. I have users that have multiple email accounts, and use our server to send all email.

Example:

email 1: user@mydomain.com pop:mail.mydomain.com smtp: mail.mydomain.com
email 2: user@someotherdomain.com pop:mail.someotherdomain.com smtp: mail.mydomain.com

Under the above setup, these users were able to send and receive email without any issues when we were on exchange 2003.

Now, under exchange 2010, they can receive email from both accounts, but they can't reply to email received from "user@someotherdomain.com"

I've gone over the "send as" permissions, and there doesn't appear to be a way to grant permissions to an account that isn't part of my domain.

Is there a possibility that this Messaging API and Collaboration Data Objects installation is causing these issues? If so, what's the best way to remove the software/repair exchange?

Bartender_1
0
Christopher McKay
Asked:
Christopher McKay
  • 8
  • 8
1 Solution
 
pclinuxguruCommented:
I run BES on the same server as exchange.

What version of BES are you using?
0
 
Christopher McKayMicrosoft Network AdministratorAuthor Commented:
Version 5.0.2 MR 1 (Bundle 25)
0
 
pclinuxguruCommented:
Sorry I misread your post. The update shouldn't have any affect on it.

So am I understanding that this works:
email 1: user@mydomain.com pop:mail.mydomain.com smtp: mail.mydomain.com

but this one does not:
email 2: user@someotherdomain.com pop:mail.someotherdomain.com smtp: mail.mydomain.com
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
Christopher McKayMicrosoft Network AdministratorAuthor Commented:
The second one does not send email. I get "5.7.1 Client does not have permissions to send as this sender." error when trying to reply to emails received on email 2.
0
 
pclinuxguruCommented:
Sounds more like a relaying issue. You may want to double check some of your smtp settings possibly compare them to the old server if it is available.

Can you explain this more. The BES account should be a domain user.
"I've gone over the "send as" permissions, and there doesn't appear to be a way to grant permissions to an account that isn't part of my domain. "
0
 
Christopher McKayMicrosoft Network AdministratorAuthor Commented:
User has an account on my network. Name: "user1@mydomain.com"
User has an account from their own domain (not hosted by us or them, hosted online) for email, Name: "user1@someotherdomain.com"

User is using a Mac computer, with email client.

These users are NOT using BES accounts. My query regarding the BES, is because it's something else in the mix that MAY be causing problems.


relay issue: Quite possibly, however, I'm not sure what I would need to change to make it work.
On Hub Transport, I have this:

Under Accepted Domains, Their "someotherdomain.com" is added as Type" External Relay" and Default is "False"


Current SMTP Settings are:

Send Connector configured on Exchange 2010 for "*.someotherdomain.com" Cost 1. Scoped send connector is NOT checked.

Under network tab, I have "Use domain name system (DNS) "MX" records to route mail automatically" selected, and "Enable Domain Security (Mutual Auth TLS) is NOT checked.
"Use the External DNS Lookup settings on the transport server" is checked.



Is there anything else I'm supposed to have?
0
 
pclinuxguruCommented:
So user1@someotherdomain.com is trying to send/receive email from your exchange server instead of someotherdomain.com's mail server?
0
 
Christopher McKayMicrosoft Network AdministratorAuthor Commented:
That's correct. I'm told that the reason is speed of connection to their server, and that I'm to just make it work like it used to work. (This worked previously on our Exchange 2003 setup, but doesn't work now on Exchange 2010.)
0
 
pclinuxguruCommented:
Well you can try this:
"Under Accepted Domains, Their "someotherdomain.com" is added as Type" External Relay" and Default is "False""

Make it true

"Send Connector configured on Exchange 2010 for "*.someotherdomain.com" Cost 1. Scoped send connector is NOT checked."

Check the box

If it doesn't work I'll look at mine and see if anything rings a bell.
0
 
Christopher McKayMicrosoft Network AdministratorAuthor Commented:
Under "Accepted Domains"

Their entry is marked false, but currently the entry for our domain is marked as "True", if I set theirs as default, will that not then mark mydomain entry as False?
0
 
pclinuxguruCommented:
Ehhh don't change anything just yet. If you did change it back.

I compared mine to yours.

In the send connector properties make sure your fqdn is correct for your exchange server.

On mine the accepted domain is an internal relay which could be a simple difference in how we do things compared to you. Internal relay should do both external and internal though.

Then for a specific user we went to the Exchange Management Console and typed this:

Get-ReceiveConnector "External Relay" | Add-ADPermission -User "Domain\User" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"
0
 
Christopher McKayMicrosoft Network AdministratorAuthor Commented:
Is it possible to do this for an AD group? rather than just a user? Or should it be done on a per user basis?
0
 
pclinuxguruCommented:
Looks like it is a per user thing. Here are the options for Add-AdPermission

http://technet.microsoft.com/en-us/library/bb124403.aspx
0
 
Christopher McKayMicrosoft Network AdministratorAuthor Commented:
I've found something that may be the cause, however, I'm not sure how to fix it.

I've found that all my tests were succeeding, but to eliminate the potential that it was my admin account, I had someone else test this.
As murphy would have it, I didn't realize that the person testing this was also a domain admin. Therefore I had never tested a standard user.

When I setup a new "standard user" account, I found that the test failed on my computer. The same computer that succeeded with my account.

So, it looks like Admins can send as an external address, but standard users cannot. Where is this setting in Exchange? What permission or role do I have to give my standard users to make this work?
0
 
pclinuxguruCommented:
Well from playing with mine and looking over my notes from our conversion there is an issue with 2010 where by default it doesn't allow authenticated users to relay.

Add-AdPermission -Identity "Default Receive Connector" -User "NT AUTHORITY\Authenticated Users" -ExtendedRights ms-Exch-SMTP-Accept-Any-Sender

(replace Default Receive Connector with the name of your connector) is what we had to do to get my test install working. Authenticated Users should work. You can try swapping NT AUTHORITY\Authenticated Users with domain\domain users.
0
 
Christopher McKayMicrosoft Network AdministratorAuthor Commented:
pclinuxguru, thanks so much for this! I've finally got it working, and have confirmed that there are no further issues on this front.

I will be accepting your solution as soon as I sort something out with an admin.

Bartender_1
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

  • 8
  • 8
Tackle projects and never again get stuck behind a technical roadblock.
Join Now