locked
Azure AD Connect group writeback and msExchnHideFromAddressLists RRS feed

  • Question

  • Latest version of AADC in use with group writeback enabled. After AADC creates the O365 Groups in AD, I run update-recipient on the group to give it mail attributes so it can be used by on-prem mail users.

     

    I've created Office 365 Groups and hidden them from the GAL using  set-unifiedgroup "group@domain.com" -HiddenFromAddressListsEnabled $True and this works to hide the O365 Group from cloud mailboxes in O365

     

    The problem is that on-prem mailboxes are still able to see the Office 365 Group in the GAL.  If I modify the group in AD and set msExchHidefromAddressLists  to TRUE than on-prem users no longer see the O365 Group in the GAL, BUT, on the next AADC Sync, the msExchHidefromAddressLists attribute is overwritten and set back to <not set>

     

    In reviewing sync rules, the Inbound rule named "Out to AAD - Group SOAinAAD" does NOT include msExchHidefromAddressLists  int he transformations, so this attribute is never getting into metaverse for any O365 Group objects.  To try and address this issue I modified a custom version of this rule and added a transformationf or msExchHidefromAddressLists and did a full sync but this attribute never comes intot he Metaverse on O365 Group objects.  I've tried a number of different ways to make this work but none do.  

     

    This seems like some kind of bug as there is an Outbound rule named "Out to AD - Group SOAinAAD" includes the msExchHidefromAddressLists  attribute in it.  This implies MSFT intends for this setting to push from AAD to AD, but since the Inbound rule doesn't have this attribute (nor can I get it to work by manually adding it), the "hide in GAL" setting of an O365 Group set in the cloud can never come down to AD.

    Is there some way to resolve this so the msExchnHideFromAddressLists attribute can be sync'd in from Azure AD as part of group writeback?


    • Edited by HDClown Tuesday, October 30, 2018 4:52 PM
    Tuesday, October 30, 2018 4:25 PM

All replies

  • I have escalated this to the product team for a workaround or confirmation. It looks like you set everything up correctly based on your description so this is either a limitation of the product or something that requires additional settings. 
    Wednesday, October 31, 2018 5:39 PM
    Owner
  • The msExchHideFromAddressLists attribute isn't brought back on-premises.  A very limited set of attributes is imported.  Another attribute that doesn't get imported/written back is msExchRequireAuthToSendTo.  It gets flowed as the constant TRUE.

    I wrote about it here: https://www.undocumented-features.com/2018/09/14/fixing-office-365-anonymous-group-write-back-and-external-delivery/

    If you want certain groups hidden, I would recommend creating a custom rule like I outlined in the above post and then create rule in AAD connect to flow TRUE for the msExchHideFromAddressLists attribute, using an attribute that we read on the inbound as a scoping filter. It's not idea, but the best way to accomplish at this point.

    Friday, November 2, 2018 3:27 AM
  • If you review the rules I mentioned, you'll see the Out to AD rule for O365 Groups has msExchHideFromAddressLists in the transformations, but the In from AAD rule for O365 Groups does not have msExchHideFromAddressLists in it.

    Why would the rule have this attribute to send out to AD but leave off the In from AAD?  It just doesn't make any sense.   Likewise, why when I add a transform for msExchHideFromAddressLists to the In from AAD rule, why does it not actually locate the attribute from the connector and send it to the Metaverse?  

    To me this reads as either some oversight on part of MSFT or some silly decision made as to why it's a "bad idea".  If you're offering group writeback in the first place in order to AD to allow features of O365 Groups to be available to on-prem mailboxes than the attribute that controls if the group should be hidden from the GAL or not should be part of that sync. 

    I think this is something the product team needs to address and make work.


    Friday, November 2, 2018 2:18 PM
  • I have escalated this to the product team for a workaround or confirmation. It looks like you set everything up correctly based on your description so this is either a limitation of the product or something that requires additional settings. 
    Is there any feedback on this?  The latest downloadable version of Azure AD Connect still doesn't sync this attribute.
    Tuesday, February 19, 2019 9:24 PM