Oct 31 2018 12:37 PM
I'm very much aware of the license requirements for Shared Mailboxes in Exchange Online and for all Shared Mailboxes we always give licensed users access to them. If we need to login to the actual shared mailbox, we assigned them a license. This could be necessary if you also have some 3rd party application that actually need to login to the mailbox and fetch e-mail for some reason.
I have recently realized that you CAN actually set a password to a Shared Mailbox. Just go to admin.microsoft.com > Users > Active Users > select the Shared Mailbox > Reset password. After this, you can login with the username/password. Of course, if you access it via portal.office.com you won't see Outlook but if you go directly to outlook.office365.com you will get access to the mailbox.
Anyone know anything more about this feature? Limitations?
I'm not looking to break the licensing terms, all our physical users for all our customers have their own personal accounts but there are scenarios where you have a 3rd party application accessing the mailbox for some reason.
Oct 31 2018 10:23 PM - edited Oct 31 2018 10:24 PM
Interesting. My approach usually is to create a "service account mailbox" (with license) to access shared mailboxes for applications.
Here is a passage from
Note
A shared mailbox is not designed for direct logon. The user account for the shared mailbox itself should stay in a Disabled (or "disconnected") state.
So while it might be technically possible, especially for applications you need to either license the mailbox or use a separate licensed mailbox for the shared mailbox access.
Quadrotech - Management, Reporting and Migration for Office 365
Oct 31 2018 10:47 PM
Hi Jonas.
Did you perform the conversion of a shared mailbox to a General mailbox?
Nov 01 2018 12:05 AM
SolutionThis "feature" has been around for years, but despite probing Microsoft numerous times about it, we haven't received a clear answer. Until we do so, assume that it's unsupported, and that it breaks the license agreement.
Applications should still be able to access the mailbox via delegate/impersonation permissions.
Nov 06 2018 03:22 AM
Jan 10 2019 11:02 AM
Hi,
Sorry for the stupid follow up question, but when you say "we assigned them a license", what exactly are you assigning the license to? Is it the associated "user" account that is tied to the shared mailbox?
I have a situation where I need a 3rd party app to log into the shared mailbox and parse the emails contained within. This application requires a username and a password to be provided to be able to connect and I am struggling a little to figure out what credentials I should be providing.
I am not an Exchange expert so I apologize if this is something straight forward to do.
Jan 22 2019 04:16 AM
A user object (in this case the user account representing the shared mailbox) that uses it's own password to access a cloud resource (in this case it's own mailbox) by whatever protocol, requires a license.
If the shared mailbox object is synchronized using AAD Connect, you must enable the user object in the local Active Directory and set a password, synchronize the object and assign a license.
If the shared mailbox object is a cloud-only object, assign a license and set the password.
-Thomas
Jan 29 2019 08:46 AM
If it requires a license and has to be enabled, is there any point in actually using a shared mailbox to begin with?
We recently set up a shared mailbox but need to be able to add it to an iOS device for mobile mail. Turns out that is not possible without going the route discussed here. The more I'm looking in to it the more I'm realizing I don't see the point in using the shared mailbox to begin with.
Feb 21 2019 09:22 AM
Mar 13 2019 04:09 PM
Mar 14 2019 11:59 AM
This doesn't work for me. My iPhone sees my account on the phone already using "identical credentials."
Mar 14 2019 02:47 PM
Yeah this will not work; the real solution for this is coming, though, but it will be in Outlook Mobile:
Mar 15 2019 03:07 AM
May 09 2019 12:08 AM
Just worked for me, a horrid way to achieve something that should be possible by default.
So I have an Office 365 tenancy with four company domain names representing two arms of the company trading with different identities however the same shared staff.
So each staff member wants to read and reply but with different email profiles.
1) You cannot create a user called john@companyone.com and then a second user or shared mailbox with john@companytwo.com as "john@" has to be unique within the tenancy.
So the work around to that is create a second user/shared mailbox with john1@companyone.com and go into Exchange ? Shared Mailbox and add in the "john@companytwo.com" under SMTP and make that default and ignore the existence of john2@, you can delete it but Exchange keeps on putting it back.
The next problem is then wanting to create two email profiles, so each company can have its own branding applied. This is where the above trick works because Outlook signature profiles are a direct 1:1 link with accounts and if you're only signing into one account which either has all email going into one address or into the main address and an extra shared mailbox which is only shared with that user you only have one account.
So the above trick which I have just tried, worked and now allows me to login with a second account in Outlook and that in turn will allow me to create a second email signature.
What a hack for a limitation of Outlook. They just need to break the 1:1 link between Accounts and Signature profiles.
May 30 2019 09:52 AM
Our issue here should have a simple solution. Having spent several years in the O365 and Azure data centers, I am now running the customer facing situations. Three employees control a shared mailbox and need to configure the "Out of Office Assistant' with an auto-reply message for all the guests who submit comments after their visit. I don't see how to do this without actually logging into the mailbox directly. Using the "Open another mailbox" feature doesn't provide access to the "Account Info" page which has the config controls such as 'Automatic Replies', 'Rules and Alerts', and 'Mailbox Settings' .
The users of this shared mailbox need to periodically update the 'Automatic Reply' throughout the year as certain events occur.
Am I overlooking some obvious dialogue box somewhere?
thanks~ dNa
Aug 03 2019 06:15 PM
Did you sort this?
We handle this from Outlook. Options like 'have server reply' need to be done from the primary profile. From Control Panel > Mail, create a new outlook profile, use shared mailbox email address and leave password blank. As long as the logged in user has delegate access to the shared mailbox, the new profile will create fine. Choose the new profile, or option for prompt. You can then open Outlook and access the features you need.
Aug 21 2019 11:41 PM
This article https://docs.microsoft.com/en-us/exchange/recipients/user-mailboxes/convert-mailboxes?view=exchserve... stated that
For room mailboxes, you can enable the associated user account, which also requires you to specify a password (which requires the Reset Password role). You need to enable the room mailbox user account for features like the Skype for Business Room System.
Aug 26 2019 02:07 PM
@dna1776 if I understand your issue,
please open the following page and log in as a user with the proper permissions for the shared mailbox:
https://outlook.office365.com/ecp
as soon as you are logged in, please try to "Open another mailbox",
and you will land in the settings of the other user where you can configure things as Automatic replies, rules, etc.
Kind regards
Spikar
Sep 09 2019 07:52 AM
@dna1776 if you still need help you can actually assign permissions to shared mailbox with auto mapping OFF by using PowerShell
Add-MailboxPermission SHAREDMAILBOXUPN -User USERUPN -AccessRights FullAccess -InheritanceType all –AutoMapping $False
And then add shared mailbox as account and it then you can set up rules , out of office message etc.
Mar 11 2020 10:17 AM
@hether licensed or not we have seen that users can login directly into a shared-mailbox with credentials. it is actually a big problem. as the expectation is that they can't access them with a password and then we also don't apply MFA to them.