The problem here is how Exchange itself works (O365):
However mails sent from inside office 365 addressed to users with
accounts in 0ffice365 continued to appear in office 365 mailboxes, and
are not routed to the mx mail server (google apps), and thus are not
appearing in google apps mail mail boxes.
This is to be expected. Exchange isn't going to send email to an external MX record for example.com if their email address is bob@example.com associated with a mailbox on the Exchange Online Org for your Office 365 domain. The routing of the email will dictate that the user is local and should be treated as such.
You have a couple of options as I see it:
Option #1:
Assuming you are using 2 distinct email domains for O365 and Google Apps you could have individual mailboxes on O365 forward any incoming email to the external Google Apps domain. I know you said your MX records go to google apps so you are probably only using a single domain name, but you could look at forwarding it to their gmail associated address instead and then setting their primary email address for new emails and replies to their real company domain email address.
In this instance the example would be:
Email to bob@domain.com > google apps mx > Office 365 route > Office 365 forwards email for bob to bob@gmail.com > google apps receives email and delivers to Bob > when Bob replies he chooses to reply as bob@domain.com instead of bob@gmail.com
Option #2
Like O365 support said, you can look into setting up the Internet Relay Domain option. What they were referring to is called Shared SMTP Namespace. I've never done it with Google Apps, but the concept is the same with them overall I would presume.
However, the issue you are running into is probably because you have actual mailboxes instead of contact email addresses only for those users. They can't have actual mailboxes on the Exchange/O365 server itself, just an O365 user ID with a contact email address.
But you'll also have to setup such a thing on Google Apps side somehow to (again not familiar with how they do it)...because otherwise you'll end up with a loop. You'll need something on their side that says "check for mailbox and if not found send to O365".
The flow would work like:
External Email to bob@domain.com > google apps receives and checks for local mailbox. If found, deliver...if not > Office 365 route > O365 delivers to mailbox there.
Office365 user emails bob@domain.com > Office 365 finds no Exchange mailbox but does see bob@domain.com as a contact > Exchange Online has the Internet Relay Domain setup for domain.com and the next hop set back to send outbound to the MX record > google apps receives email and delivers to Bob's mailbox locally on Google Apps.
Again, you'll need to make sure that Google Apps knows to check for bob@domain.com mailbox locally before sending everything else on to O365. Otherwise it will cause a mail routing loop.
Hope that helps.
You can't export Exchange Online mailbox directly to PST via PowerShell with built-in tools. Required New-MailboxExportRequest doesn't exist Online (or is not exposed to us mortals).
You can:
- eDiscovery, that seems to be GUI-only.
- Offload/migrate mailbox to on-prem Exchange and run New-MailboxExportRequest on-prem (and migrate back to Exchange Online if needed)
- Use various 3rd party tools, that perform export via EWS or MAPI
- Script delegation full access, Outlook bind to delegated mailbox and export to PST. Technically very likely possible but I've never seen anyone do it. I haven't looked deeply into eDiscovery but I believe that's more-less how eDiscovery does export to PST (Old Exchanges also used to bind to Outlook for PST export). But without significant MAPI experience, Outlook COM model is quite complex to use (I've done some Outlook scripting but emulating PST export is challenging to say the least).
I'm as frustrated as you are. Exporting mailboxes for departing users for long-term storage is needlessly annoying. If we could just export to Azure Blob just as with import, it'd be a good start.
Best Answer
The native Office 365 PST network import tool will not give you any tools to filter/remove duplicates: https://support.office.com/en-us/article/Use-network-upload-to-import-your-organization-s-PST-files-to-Office-365-103f940c-0468-4e1a-b527-cc8ad13a5ea6
Your options are limited to:
Use a third party tool to import PST: this will have the option to stop duplicates from being imported into the mailbox. Those are usually paid for and will cost you, I'm listing this in case you have a large number of users who needs their data imported.
Import using Outlook: You can use Outlook import filters to detect and stop duplicates from being imported to the mailbox. https://support.office.com/en-us/article/Import-email-contacts-and-calendar-from-an-Outlook-pst-file-431a8e9a-f99f-4d5f-ae48-ded54b3440ac?ui=en-US&rs=en-US&ad=US
Switches in the native Office 365 PST network import tool: I know this doesn't remove duplicates, but in case the above fails, you can restore a PST to a subfolder of your choosing using the "TargetRootFolder" option.
Trim the data before importing: Again, it doesn't remove duplicates, but you may choose to restore data up to a specific date, maybe continue where the data was cut off? https://support.office.com/en-us/article/Filter-data-when-importing-PST-files-to-Office-365-26af16df-34cd-4f4a-b893-bc1d2e74039e