SOLVED

Invite Contacts as Guests feature - Updates Not Linked?

Steel Contributor

Love the new feature with Roadmap ID 15043 that lets us add Exch Online Mail Contacts as Guests to O365 Groups. I'm a little confused on how you expect us to manage Mail Contacts going forward though.

 

Adding Mail Contacts as Guests to an O365 Group appears to create a new AAD Guest User object. When I update the Mail Contact (say, I need to change their last name or email address) the AAD object doesn't update - I have to manually go into AAD and update the Guest User's info. There's no reminder in the Exchange Admin console that you'd have to do this. You can imagine how much a nightmare this can be if that Mail Contact is the member of 20+ O365 Groups and you forget to take the extra step of updating their AAD info as well as their Mail Contact info.

 

Is the solution here to stop managing contacts in Exchange and manage everything using AAD Guest User objects going forward? Or will there be the option to sync Exchange Mail Contact info with AAD Guest User info in the future? We're trying to go all in with O365 Groups but this is adding some unnecisary overhead to managing our clients.

5 Replies
best response confirmed by Paul Youngberg (Steel Contributor)
Solution

I think I addressed this point in https://www.petri.com/office-365-groups-mail-contacts. 

 

"Behind the scenes, Office 365 creates a new guest user object using the properties of the mail contact. The mail contact is unaltered so that it continues to appear in address lists and keeps its membership in distribution groups."...

 

"Two objects with the same email address now exist in the tenant. Over time, when guest user objects offer the same functionality as mail contacts, you might be able to remove the mail contacts."

 

The issue is that each object serves different purposes. Guest user objects don't appear in the GAL, DLs, etc. whereas mail contacts do... One object comes from Exchange, one is essentially adapted from SharePoint sharing.

 

I can see why Microsoft adopted this approach to solve the problem as a lot more engineering effort would probably have been needed to upgrade mail contact objects to act as external guest user objects.

 

That makes sense, thanks Tony! I'm still hoping someone from the MSFT team chimes in with a peek into to their vision for Guest User objects.

Would be happy in the short-term to see invitations sent from O365 ask for more than just an email address. As it stands now, when a guest gets added to an O365 Group through OWA or Outlook the AAD object that's created doesn't contain a first or last name. It can get confusing real quick determining who's who when looking at the member list. The only fix now is for the admin to go into Azure AD after the fact and manually add that info to each AAD object.

I suspect that we will move away from the current implementation of guest user objects, if only because these are based on the sharing mechanism for SharePoint and it might be difficult/impossible to bring the same mechanism forward for applications like Planner and Teams. I argue for a common external access mechanism that works across all Office 365 applications in https://www.petri.com/common-external-access-office-365. 

1 best response

Accepted Solutions
best response confirmed by Paul Youngberg (Steel Contributor)
Solution

I think I addressed this point in https://www.petri.com/office-365-groups-mail-contacts. 

 

"Behind the scenes, Office 365 creates a new guest user object using the properties of the mail contact. The mail contact is unaltered so that it continues to appear in address lists and keeps its membership in distribution groups."...

 

"Two objects with the same email address now exist in the tenant. Over time, when guest user objects offer the same functionality as mail contacts, you might be able to remove the mail contacts."

 

The issue is that each object serves different purposes. Guest user objects don't appear in the GAL, DLs, etc. whereas mail contacts do... One object comes from Exchange, one is essentially adapted from SharePoint sharing.

 

I can see why Microsoft adopted this approach to solve the problem as a lot more engineering effort would probably have been needed to upgrade mail contact objects to act as external guest user objects.

 

View solution in original post