As organisations grow, or have to separate different business areas in different O365 tenants it would be useful to be able to share or federate global address lists between different tenants. The only current choices are:

1. Create contact objects in tenants which are then disconnected from the original user - this means if the user details change the contact in the other tenant becomes out of sync.




2. Where domain federation in in place and directory synchronisation services running for each tenant, create on premise AD users as mail enabled users and ensure each directory sync for each tenant looks at the other domains. This will ensure that user objects are sync'd to the other tenant as mail contacts.

The second method works quite well from a point of ensuring that user details are always accurate with AD objects but only works in an environment where domain federation and dirsync are used. This is not an option in a completely cloud based environment.

Allowing GAL federation/sync between tenants would reduce on premise administrative burden and also provide a solution for cloud only adoption.

I created an account for a client of mine. I set it up on my company (registered in Sweden) to be able to fix this smoothly for my customer. When I now want to change ownership to his company (registered in Switzerland) I cannot do that. That is strike one.

Ok, so I was told that I should setup a new account and then you could help me migrate all data to the new account, so I did. When I came back asking for the migration step I get the instructions to do this via exporting to pst-files. I MEAN COME ON!! What year is this?

Now my only hope is that I can use migrationwiz or something else to be able to migrate the data. All this because I cannot change the owner of an account.

So what is my proposal:
1. Either make it so that you are able to change ownership of an account (I think lots of SMBs out there would benefit from this) or,
2. Help the customers with the migration - should be much hassle for you guys.

That would be greatly appreciated!

Short:

On shared mailboxes in office 365 emails that are flagged by the sender as private are hidden. In OWA they are visible.

Long:

Users having full access to the shared mailbox do not see emails sent with a private flag - and they do not get informed about it. The emails are just silently hidden by outlook without any further notice. Quite stupid, for a shared mailbox (e.g. incoming orders!)

We discovered that by coincidence: Our users were concerned because the number of unread emails was increasing - although there were no unread emails visible for them.

If they open the same mailbox in OWA, they can actually SEE the private email!

Improvement:

1. Get consistent behavior between OWA and Outlook.




2. Let an administrator configure right to see the private messages on shared mailboxes.

For an international company, it is important to define the company language (e.g. English) as the default language. Unfortunately, when initializing O365, the language is set according to the location (in our case "German"). This is devastating because all SharePoint pages (including OneDrive) are subsequently created in "German". This should at least be pointed out.
Unfortunately there is no possibility to change the default language afterwards. The workarounds with multi-language support are not satisfactory. Nevertheless, German continues to dominate in many areas

Please point out the importance of the language during the initial setup and give the possibility to select the default language. As an alternative, it would be good if Microsoft provides a way to change the default language afterwards.

Tenant administrators should have the ability to specify whether or not new features such as Teams, Sway, etc. are enabled by default within their tenants. Just like there's the ability to set a tenant to receive First Release, Admins should be able to specify how changes are introduced to their environment. It's great that there are Powershell commands to turn features on/off but it would be much easier to either set these new features to be off by default, or enable Admins to enable when organizations are ready to absorb those changes. Functionality like Teams is absolutely fantastic, but without the right change management planning it becomes confusing for users. For Tenant Admins that either ignore announcements of new features, or are unavailable to turn them off when they become available - this is an appropriate solution to enable organizations to effectively manage how they are consuming Office 365.