IT colleagues:
Earlier this month the Exchange Administrators identified a small number of on-premises Active Directory groups that had previously been mail-enabled and then later had that functionality disabled. These groups were still mail-enabled in Azure with an unsupported Azure email address. We took steps to remove the Azure mail component to mirror the on-premises AD group where it originates. A list of impacted groups and their object location is available here.
Impacted local IT support groups should review the list to determine if the group is still needed, but no immediate action is required. These groups may still be in use for other services and action should be taken on a case-by-case basis.
How does this happen?
When an on-premises group is mail-enabled, it syncs to Azure and gets an Azure email address (@indiana.onmicrosoft.com) stamped onto it as a secondary address. When the on-premises group gets disabled, the @exchange.iu.edu address gets removed but Azure retains this secondary address and assigns it as the primary address. This means that when you email that group, it still works, but gets sent from the @indiana.onmicrsoft.com address.
What did the Exchange Admins do?
After identifying the affected AD Groups, we removed the Azure object without changing the on-premises group. This forced the group to re-sync back to Azure without this secondary email. There should be no impact to any permissions or membership for these groups.
How does this affect your clients?
In some cases, clients may have been using outdated contacts and sending emails to these pseudo mail-enabled groups. Emails were still being sent out through the Azure-based address, despite the group no longer being mail enabled in Active Directory. These groups will no longer work if you try to send email to them, and clients may encounter issues.
Why does my affected AD Group say [System.Object]?
In these cases, the problematic email address in Azure has been removed, but an on-premise version of that email address may exist on a different AD group with a mismatched name. For example, this could happen if a group wanted to keep the historical email address, but assigned it to an ACM group when they mail-disabled the original group. Those emails are still in place, but when searching for affected AD groups you will return multiple results. These may need to be resolved on a case-by-case basis by the local IT support.
What are the best practices moving forward?
We are working with the Tier 2 Desktop, Server, Mobility team to update existing Knowledge Base documentation on this. When a mail-enabled distribution group is no longer needed, the group should either be deleted from Active Directory or Tier 2 should be contacted if the group needs to be disabled so the Azure component may be removed to fully disable the mail component.
If you have questions or concerns about this, please contact Tier 2 at sct2@iu.edu.
–IT Community Partnerships on behalf of the Exchange Administrators