Guest users have become a “standard” feature of every Office 365 tenant out there, as many of the collaboration features within the suite depend on them. In the case of Microsoft 365 Groups and Teams, guests can be added as members and participate in conversations, get access to documents and more. But as Guest users do not get a mailbox within the resource tenant (at least not if you stick to the “supported” means), there are some challenges with few parts of this experience. The lack of mailbox means they cannot access “conversations” within the Group mailbox directly and instead need to be “subscribed” in order to receive them directly in their home mailbox.
Another issue is caused by a change Microsoft introduced a while back, which changed the behavior of sender’s copies of messages they send to a given group. Whereas previously Microsoft 365 Groups followed the behavior of “traditional” Distribution groups and “echoed” the message back to the original sender, the change caused such copies to stop being delivered to the original sender. In theory, this is not needed as one could always access the copy from their own Sent Items or the Group mailbox itself. Then again, in the case of Guest access, the latter is impossible, and in this article we will see how to remedy it. But first, let’s continue with the history lesson.
Since the aforementioned change hit tenants without much fanfare and caught many people off guard, some initial backlash followed. In turn, this caused Microsoft to provide an option to control this behavior. Interestingly though, Microsoft chose to control this on the user side, and not on the Group object itself. The “solution” introduced a new parameter, EchoGroupMessageBackToSubscribedSender, configurable via the Set-MailboxMessageConfiguration cmdlet. A corresponding UI setting was also made available under OWA > Settings > Mail > Groups, as shown below:
While the controls detailed above address the issue and provide some sort of flexibility for users, the Guest scenario remained unaddressed. As guests do not get a mailbox within the resource tenant, they cannot access OWA to configure the setting, and neither can an administrator run the Set-MailboxMessageConfiguration cmdlet against their GuestMailUser object. Or can they?
In what looks to be yet another undocumented change, we can now run the Set-MailboxMessageConfiguration cmdlet against Guest users. More importantly, the changes we made actually take effect, as is the case with the EchoGroupMessageBackToSubscribedSender property. Let’s illustrate this with an example. First, we will need a list of all Guest users, which we can obtain via the following cmdlet:
#List all GuestMailUser objects Get-Recipient -RecipientTypeDetails GuestMailUser Name RecipientType ---- ------------- vasil_michevdev3.onmicrosoft.com#EXT# MailUser Guest_c02a90ac99404ad4b1012d76543ff5a3 MailUser b5f16f75-44a2-480e-aacf-9d5a19434e26 MailUser
Take the first object returned, vasil_michevdev3.onmicrosoft.com#EXT#. To verify he’s a member of at least one Microsoft 365 Group, we can run another query to filter based on the Members property. First, we need to obtain the guest user’s DistinguishedName value, and then pass it along. Here’s how it works:
#Get the DistinguishedName value $dn = (Get-MailUser "vasil_michevdev3.onmicrosoft.com#EXT#").DistinguishedName #Filter based on the DN Get-Recipient -Filter "Members -eq '$dn'" Name RecipientType ---- ------------- default_8d405d20-65d9-4650-abca-352770e4438b MailUniversalDistributionGroup Team_c7442983-e654-40b1-a73b-fef16f6a88e6 MailUniversalDistributionGroup #Better yet, filter just Microsoft 365 Group objects Get-UnifiedGroup -Filter "Members -eq '$dn'" Name DisplayName GroupType PrimarySmtpAddress ---- ----------- --------- ------------------ default_8d405d20-65d9-4650-abca-352770e4438b Default Universal default2@michev.info Team_c7442983-e654-40b1-a73b-fef16f6a88e6 TeamOne Universal Team@michev.info
OK, so now we have a Guest user that’s a member of at least one Microsoft 365 Group. Let’s see what happens if we try to configure the EchoGroupMessageBackToSubscribedSender property on his GuestMailUser object. To do so, run the following cmdlet:
#Set EchoGroupMessageBackToSubscribedSender on a Guest user Set-MailboxMessageConfiguration "vasil_michevdev3.onmicrosoft.com#EXT#" -EchoGroupMessageBackToSubscribedSender $true
Surprise surprise – the cmdlet run successfully, which you can verify by subsequently running the Get-MailboxMessageConfiguration cmdlet against the guest user object. More importantly, the setting actually takes effect, as we can quickly verify by sending a test email using the Guest user’s own mailbox within his home tenant. The output of the Get-UnifiedGroup cmdlet above gives us the email address of the Microsoft 365 group to try this, but remember that the Group must be enabled for receiving external messages!
It all seems to work, and the Guest user can now see copies of his own messages sent to any Microsoft 365 Groups within the resource tenant. Of course, it would have been nicer if the Guest user himself had a method to configure this, as currently you will need an admin intervention. Still, it’s good to know that options exist.
Should you want to toggle this for all your Guest users in bulk, here are some cmdlets that can help. We already saw how to get the list of all Guest users above, and once you have the list you can pipe it against the Set-MailboxMessageConfiguration as follows:
Get-Recipient -RecipientTypeDetails GuestMailUser | Set-MailboxMessageConfiguration -EchoGroupMessageBackToSubscribedSender $true
It’s also interesting to see what other cmdlets can be used against Guest mail user objects and which properties can be toggled. Below is a short (and definitely non-exhaustive list) of things I’ve tried:
- Get-MailboxAutoReplyConfiguration – the cmdlet works and will return the auto-reply configuration for the Guest user object.
- Set-MailboxAutoReplyConfiguration – the cmdlet also seem to work, properties can be updated and the changes seem to be reflected in the output of Get-MailboxAutoReplyConfiguration. No actual OOO reply was sent in my tests however.
- Get-MailboxCalendarConfiguration – the cmdlet cannot be used against a Guest mail user object.
- Get-MailboxJunkEmailConfiguration – works.
- Set-MailboxJunkEmailConfiguration – seems to work, changes are reflected. Unclear if they actually take effect.
- Get-MailboxMessageConfiguration – works.
- Set-MailboxMessageConfiguration – works, changes are being reflected (where it makes sense).
- Get-MailboxRegionalConfiguration – the cmdlet does not work against Guest mail user mailboxes
- Get-MailboxSpellingConfiguration – the cmdlet does not work against Guest mail user mailboxes.
- *-Mailbox – the cmdlets do not work against Guest mail user objects.
- Get-MailboxStatistics – does not work.
Keep in mind that most of the settings you can toggle with the cmdlets that do work cannot be tested. For example, any of the settings that change OWA settings cannot be tested, as we cannot access OWA as a Guest mail user. Similarly, changes that apply on message sent/receive events, such as OOO replies or auto-signature also cannot be tested.
It’s also interesting to note that “plain” Mail user objects also get the same treatment, i.e. you can run the Set-MailboxMessageConfiguration cmdlet against them. While I can find some logic in why the cmdlet works against Guest mail users or mail users corresponding to Hybrid mailboxes (in other words, objects that are covered by the compliance framework via the so-called “shadow” mailboxes or “shards”), “plain” mail users should not get the same treatment, afaik. I suppose something has changed therein, too.