Overview
When using the Kerio Exchange Migration Tool (KEMT) to migrate from Microsoft Exchange 2016 or Later to Kerio Connect, the tool may successfully connect to both servers but fail to enumerate (list) any mailboxes from Exchange. The tool shows an empty user list despite having proper administrator permissions configured.
Symptoms:
- KEMT connects successfully to Exchange 2016 and Kerio Connect servers
- No mailboxes appear in the user list within KEMT
- Administrator account has all required Exchange permissions (Organization Management, Application Impersonation)
- Outlook profile is configured correctly with Cached Exchange Mode disabled
- Manual mailbox access via Outlook works normally
Error Messages in Debug Logs:
0x00040380 MAPI_W_ERRORS_RETURNED: Obtaining HomeMTA failed0x80070057 E_INVALIDARG: CreateStoreEntryID failedHomeMTA error: -2147221233
Solution
The issue occurs because Exchange 2016 (or later versions) does not automatically populate the homeMTA (Home Message Transfer Agent) attribute in Active Directory for user accounts. However, KEMT's underlying MAPI interface expects this attribute to be present for proper mailbox enumeration. By manually setting the homeMTA attribute on the administrator account used for migration, the tool can successfully discover and list Exchange mailboxes.
Step 1: Open Exchange Management Shell
On your Exchange server, open Exchange Management Shell (not regular PowerShell). You can find it in:
- Start Menu → Microsoft Exchange Server 2016 → Exchange Management Shell
Run it with administrator privileges.
Step 2: Verify Current Attribute State
First, check if the homeMTA attribute exists for your migration admin account:
# Replace "admin_username" with your actual admin account username
Get-ADUser -Identity "admin_username" -Properties msExchHomeServerName, homeMTA, legacyExchangeDN | Select-Object Name, msExchHomeServerName, homeMTA, legacyExchangeDN
If the homeMTA field is empty, proceed to the next step.
Step 3: Construct the HomeMTA Distinguished Name
Run the following Exchange Management Shell commands to automatically generate the correct homeMTA value for your environment:
# Get the Exchange server's MTA DN $ExchangeServer = (Get-ExchangeServer)[0].Name $ConfigNC = (Get-ADRootDSE).configurationNamingContext $ExchangeServerDN = (Get-ExchangeServer $ExchangeServer).DistinguishedName # Construct the HomeMTA DN $HomeMTA = "CN=Microsoft MTA,$ExchangeServerDN" # Display it Write-Host "HomeMTA value: $HomeMTA"
The output should look similar to:
CN=Microsoft MTA,CN=ServerName,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=OrganizationName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=com
Step 4: Set the HomeMTA Attribute on the Admin Account
Apply the homeMTA attribute to the administrator account being used for migration:
# Set your admin username
$AdminUser = "admin_username"
# Apply the homeMTA attribute
Set-ADUser -Identity $AdminUser -Replace @{homeMTA=$HomeMTA}
# Verify it was set correctly
Get-ADUser -Identity $AdminUser -Properties homeMTA | Select-Object Name, homeMTA
Success Check: The output should now show the homeMTA attribute populated with the Distinguished Name constructed in Step 3.
Step 5: Wait for Active Directory Replication
Allow 2-3 minutes for Active Directory replication to complete, especially in multi-domain controller environments.
Step 6: Restart Outlook and KEMT
On the migration workstation (Windows Server running KEMT):
- Close the Kerio Exchange Migration Tool completely
- Close Microsoft Outlook
- Reopen Outlook and verify connectivity
- Reopen KEMT
Step 7: Test Mailbox Enumeration
In KEMT:
- Navigate to the Exchange connection configuration
- Click to refresh or enumerate mailboxes
- Verify that the user list now populates with Exchange mailboxes
Note: If you have multiple domain controllers, ensure the admin account credentials used in KEMT are authenticating against a DC that has received the updated attribute information.
Summary
Exchange 2016 does not populate the homeMTA attribute by default, but the Kerio Exchange Migration Tool's MAPI interface requires it for mailbox enumeration. By manually setting the homeMTA attribute on the migration administrator account using PowerShell commands in Exchange Management Shell, you resolve the MAPI_W_ERRORS_RETURNED and CreateStoreEntryID failed errors, allowing KEMT to successfully discover and list Exchange mailboxes for migration.
Additional Resources:
FAQ
Q1: Why doesn't Exchange 2016 populate the homeMTA attribute automatically?
A1: Exchange 2016 uses modern MAPI over HTTP protocols and doesn't rely on the legacy homeMTA attribute for normal operations. However, some migration tools like KEMT still use older MAPI APIs that expect this attribute to be present.
Q2: Do I need to set homeMTA for every user account or just the admin account?
A2: You only need to set the homeMTA attribute on the administrator account that KEMT uses to connect to Exchange. Regular user mailboxes do not require this attribute for the migration to work.
Q3: Will setting the homeMTA attribute affect my Exchange 2016 server's normal operations?
A3: No. Adding the homeMTA attribute to an admin account does not impact Exchange 2016's functionality, performance, or user mailboxes. It simply provides backward compatibility information that legacy MAPI clients may reference.
Q4: What if I still see errors after setting homeMTA?
A4: Ensure you've waited for Active Directory replication (2-3 minutes), restarted both Outlook and KEMT, and verified the attribute was set correctly using Get-ADUser -Identity admin_username -Properties homeMTA. Also confirm that Cached Exchange Mode is disabled in the Outlook profile and that the admin account has the required Exchange permissions (Organization Management, ApplicationImpersonation).
Ciprian Nastase
Comments