sukh

Then you shouldnt need to do what youre doing, internal relay. Your MX records will point to either your RM server or your Exch server, which will query AD for the proxy addresses and delver email to recipients, if they exist or NDR if they dont. If not senders will receive the standard NDR. Unless RM do 'funny' things?

RM server in a different ORg?

the above would work but if tyhe recipient doesnt exist at your Org then why forward to RM mail server? Still will get an NDR? What's the objective here?

1. Check on your SMTP connector to the internet to see if there is a smarthost specified or not? Or are you using DNS to send emails? 2. Check on the SMTP virtual server to see if there is a smart host specified there? 3. If the Exch server that send out emails hasn't changed and the IP (public facing) hasnt changed then yu shouldn't need to worry about your PTR and SPF records. 4. Up the protocol logging for SMTP and then PM or post the results here. - Logging the SMTP Service 5. Can you also PM the entire NDR? 6. Also, is the for every sender sending to ANY External SMTP domain? Or some domains? Thanks Sukh

1. On your shared mailbox have you given the send as permission for all 5 users? 2. Are these 5 users members of any admin groups like account operators, print operators, domain admins, backup operators? Check for nested groups too. 3. Do you want to send as that user or send on behalf? Send as the use send as per, send on behalf then use Outlook delegates 4. In outlook when you compose the message, choose the From field and enter the shared mailbox email address.

1. When did this change take place? 2. Do you have a different smarthost that you have to use now? 3. Do you use DNS to send email or smarthosts? 4. Are your PTR records setup correctly? 5.SPF records?

make sure you get a 3rd party cert and not a self signed, you will run into issues.

well you know it's some GPO (domain or local) which is stopping this, check out any restrictec groups and go through your GPO's to pinpoint

Yes, nothing will be different.

then you dont need to worry about the legacy name space and just make sure you switch over your public dns IP to pont to the new 2010 server and amened your firewall rules, and you mx records, create your send connectors and youre done. If using PF folders replication then, and setup your OAB

1. You should setup your DNS beforehand, - setup the legacy namespace beforehand 2. Run through this - Exchange Server 2010: Exchange 2010 SP1 Help 3. OWA access depends if its from external or inernal and if you want to co-exist?

1. So you can reproduce the issue? 2. Checked different browsers? 3. Disabled add-ins in IE? Tried IE in safe mode? 4. All users effected? 5. Cleaned temp IE files? 6. Created as a test a new windows profile? 7. If you create a new user, same issue internally & externally?

1. You can install Exch 2010 and all the roles, (CAS/HUB?MBX). Exch will create the InterOP connectors and sit there and do nothing. 2. Only if you start to move users, then Exch 2010 will be used, i.e mai routing to 2007 users and you will have to create a send connectot to the internet. 3. If this moved user on Exch 2010 tries to access OWA externally, then this will need to be setup. 4. This is why is depends, if you plan to move all users to Exch 2010 in one big hit over the weekend or over a period of time. If over a time and you want all functionality/service there, then you will have to setup co-exist env for OWA, EAS, OA etc... 5. Here' some links you should read - Upgrading Outlook Web App to Exchange 2010 - Exchange Team Blog - Site Home - TechNet Blogs & Exchange 2007 - Planning Roadmap for Upgrade and Coexistence: Exchange 2010 SP1 Help

1. Installing Exch 2010 wont have any effect on your 2007 env unless you start to move users acorss to it or start to change DNS/publishing from 20007 to 2010. 2. Install Exch 2010, make sure youre happy with it then you can switc over your MX records to 2010 for mail delivery. 3. Webmail is different and you need to consider this too. Eihter a migration over the weeked or co-existence scenario. Depends on your deployment/migrations stratgey.

1. Then I'd suspect the same, transit, MTA, ISP issue. Post back.

1. You can create a script to create mailboxes, but to have a script do what you want to, i.e if a new user is created in an OU, and you want that script to automatically check that OU for new users and then provision the mailbox, will take some effort writing. 2. Most Env I have seen this in use 3rd party products, which can be costly.

1. Could be issue in transit or with your Exch. 2. Are you saying you can get emails from say hotmail, google and other domains? 3. Is the issue only with this one sender domain? 4. Post the full NDR.

1. Not sure why SMIME would fix that, 2. Have you launcging IE in safe mode and tested

I thought you wanted to change the port, then configure SP, In IIS you should be able to change the port used by SP, then configure SP to use the mail servers (hosted)

Is that name in the GAL or another address list? Or is it a local contact Created a new Outlook profile and tested?

ve you tried changing the port via IIS used by SP?

1. To rule out Exch, just simply test with the same mail account on another PC in a different rule, if it all works, then it wouldpoint to your client build.

Have you tried changing the port via IIS used by SP?

1. I'll need to look into this, are Sharepoint is on--premise I take it?

1. You shouldnt have to, it;s applied at that database level so any new mailboxes created on that database will inherit the permission.