How to Decommission Exchange Server When Mail-Enabled Security Groups Control NTFS File Permissions

The problem nobody warns you about

When you decommission on-premises Exchange Server and migrate mail to Microsoft 365, one category of groups trips up even experienced admins: mail-enabled security groups that also control NTFS file permissions.

The groups look ordinary in Active Directory. They have email addresses. They distribute mail. They also appear in the Access Control tab on file shares, granting read or modify permissions to whoever needs file access.

Then you migrate those groups to the cloud, and file access breaks.

This happens because mail-enabled security groups are dual-purpose objects. They exist in two worlds simultaneously: the on-premises AD world (where they control file permissions via SID) and the Exchange world (where they route mail). When you migrate the mail function without separating it from the file permission function, the SID changes. NTFS permissions, which are stored as SIDs and not names, immediately lose their target. The permissions vanish even though the group name still looks correct in the access control list.

The solution is not to migrate the group. It is to replace it with two separate objects before you touch anything.

Step 1: Inventory all dual-purpose groups before you do anything else

The first step is to find every mail-enabled security group in your organization that also has NTFS permissions on file shares. Do not skip this. If you miss even one group, you will spend time restoring access after the migration instead of preventing the outage.

Run this PowerShell command to find mail-enabled security groups in Active Directory:

Get-ADGroup -Filter {GroupCategory -eq "Security" -and Mail -ne "$null"} -Properties Mail, Description |
  Select-Object Name, SamAccountName, Mail, Description |
  Export-CSV "C:\Temp\MailEnabledSecurityGroups.csv" -NoTypeInformation

This gives you a list of every security group that has a mail attribute. From this list, cross-reference your file shares. Any group that appears in both the CSV and on a file share Access Control List is a dual-purpose group.

Alternatively, audit your file shares directly and extract every security principal that has been granted access, then match those against your mail-enabled groups:

$shares = Get-ChildItem \\FileServer\Shares -Directory
foreach ($share in $shares) {
    $acl = Get-Acl $share.FullName
    $acl.Access | Where-Object { $_.IdentityReference -match "yourdomain" } |
        Select-Object IdentityReference, FileSystemRights
}

Document the results. For each dual-purpose group, record which file shares it grants access to and what level of access (Read, Modify, Full Control).

Step 2: Create replacement AD security groups for file access

For each dual-purpose group, create a new, mail-disabled AD security group that will take over the file permission function.

New-ADGroup -Name "FileAccess-SEC-" `
    -SamAccountName "FileAccess-SEC-" `
    -GroupCategory Security `
    -GroupScope DomainLocal `
    -Path "OU=FileAccessGroups,DC=yourdomain,DC=com" `
    -Description "File access only - migrated from  on $(Get-Date -Format 'yyyy-MM-dd')"

The naming convention matters. Use a prefix that makes the group type obvious (FileAccess-SEC) so nobody accidentally mail-enables it later. Put these groups in a separate organizational unit that is excluded from your Azure AD Connect sync if you use one.

Step 3: Migrate NTFS permissions first, before touching mail

This is the critical step. Replace the dual-purpose group with the new file-access-only group on every file share ACL, then verify file access works with the new group alone.

In Windows Explorer or via icacls, replace the dual-purpose group with the new security group on each affected share:

# Add the new group to the share ACL
icacls \\FileServer\ShareName /grant "yourdomain\FileAccess-SEC-OriginalGroupName:(OI)(CI)RX"

# Remove the old dual-purpose group
icacls \\FileServer\ShareName /remove "yourdomain\OriginalGroupName"

Test file access immediately after making each change. Have a user who was granted access via that group confirm they can still open the share and read or write files as expected.

Do not move the mail function until file access is confirmed working with the new group alone.

Step 4: Migrate the mail function to Microsoft 365

Once file access is stable with the new security groups, migrate the mail function. You have two paths:

**Option A: Microsoft 365 Group**

Create a new Microsoft 365 Group and migrate members to it. There is no direct in-place conversion from an AD mail-enabled security group to a Microsoft 365 Group. The recommended path is to provision a new M365 Group, add members, update any application references that point to the old group email address, and then deprecate the original group after validation.

# Connect to Exchange Online
Connect-ExchangeOnline

# Create the new Microsoft 365 Group
New-UnifiedGroup -DisplayName "" `
    -Alias "OriginalGroupName" `
    -PrimarySmtpAddress "OriginalGroupName@yourdomain.com" `
    -EmailAddresses "SMTP:OriginalGroupName@yourdomain.com", "OriginalGroupName@yourdomain.onmicrosoft.com"

# Add members from the original group
$members = Get-ADGroupMember -Identity "OriginalGroupName" | Select-Object -ExpandProperty SamAccountName
foreach ($member in $members) {
    Add-UnifiedGroupLinks -Identity "OriginalGroupName@yourdomain.com" `
        -Links $member `
        -LinkType Members
}

**Option B: Cloud-only distribution list**

If you do not need Teams integration, create a new cloud-only distribution list and update any application references that point to the old group email address.

New-DistributionGroup -Name "Migrated-" `
    -PrimarySmtpAddress "Migrated-OriginalGroupName@yourdomain.com" `
    -Type Distribution

Option A is usually preferable for groups that actively distribute mail to members and benefit from Teams collaboration. Option B is simpler when the group primarily handles internal email routing.

Step 5: Validate after migration

After migrating the mail function, run two checks:

1. Confirm email delivery works. Send a test message to the group address from an external account and from an internal account. Verify delivery to all expected members.

1. Confirm file access still works. Have the same test users verify they can still access every file share the group previously controlled. Compare against your inventory from Step 1.

If email delivery works but file access fails, the wrong SID was added to the share ACL. Go back to the share ACL and verify the replacement group is present and the original dual-purpose group is fully removed.

If file access works but email does not deliver, the cloud migration of the mail function did not complete correctly. Check the distribution list membership in Exchange Online.

Step 6: Decommission the original on-premises dual-purpose group

After validating both mail delivery and file access, disable or remove the original on-premises dual-purpose group. Do not delete it immediately - leave it disabled for 30 days in case something was missed.

Set-ADGroup -Identity "OriginalGroupName" -Enabled $false

After 30 days, if no access issues have surfaced, delete the group:

Remove-ADGroup -Identity "OriginalGroupName"

FAQ

**Why does moving a mail-enabled security group break NTFS permissions?**

NTFS permissions are stored as Security Identifiers (SIDs), not group names. When you migrate a mail-enabled security group to the cloud, its SID changes because it becomes a different object type in Azure AD. The ACL on your file share still references the old on-premises SID, which no longer resolves to anything. The result is that permissions appear to vanish even though the group name still looks correct in the ACL.

**Can I just use Azure AD Connect to migrate these groups?**

Azure AD Connect can synchronize groups, but it does not separate dual-purpose groups into two distinct objects. If a mail-enabled security group has both file share permissions and a mail attribute, Connect will migrate it as a single object. The SID will change, and NTFS permissions will break. The only fix is to replace the group in the ACL before migration.

**What if I migrate the group and only discover the file access problem after the fact?**

If you have already migrated and file access is broken, you have two options. First, re-enable the original on-premises group if it has not been deleted. Add it back to the affected share ACLs as a temporary measure while you create new security groups and migrate permissions properly. Second, use the file share audit logs to identify which users lost access, grant them temporary access directly, then migrate to the new security group structure as described above.

**How do I prevent this from happening in the future?**

Before any Exchange Server decommissioning project, audit all mail-enabled security groups and cross-reference them against file share ACLs. Establish a rule that no security group can be both mail-enabled and appear on an NTFS ACL. Use separate groups for mail and file access going forward. This makes future migrations safe and reduces the risk of silent permission loss.

**Does this apply to distribution lists as well?**

Distribution lists do not control NTFS permissions, so the SID problem does not apply. Only mail-enabled security groups are affected because they are the only group type that can simultaneously appear in an ACL and have a mail attribute. Plain distribution lists (non-security groups) cannot be granted NTFS permissions in the first place.