Exchange 2013 Active Directory property ‎homeMDB‎ is not writeable on recipient

When trying to migrate users from Exchange 2007 to Exchange 2013 you may see the following error below:

 Error:MigrationPermanentException: Active Directory property ‎'homeMDB‎' is not writeable on recipient ‎'domain.local/users/employee.smith‎'. --> Active Directory property ‎'homeMDB‎' is not writeable on recipient ‎'domain.local/users/employee.smith‎'.

With many Exchange issues the solution is to set the correct permissions to allow Exchange to migrate the mailbox.

To resolve this issue follow these steps:

1. Launch Active Directory
2. Click on View and select Advanced Features
   
   
   
   
   
3. Now location the users mailbox you are having the issue with and select properties
4. Now click on the security tab
5. Next select Advanced
   
   
        
6. Now place a tick in the "Include inheritable permissions from this objects parents" box and click OK
7. It may take a few minutes for this change to take effect but once it has you should be able to migrate the users mailbox without any problems. 

Unable to sync phone to Exchange

If you've been following my blog for the last few weeks you'll have heard me talk about the Exchange 2013 migration project I've been working on.  Well we hit another snag in the migration the other day around the users mobile phones not syncing to the new mailbox server after moving to Exchange 2013.

At first we thought it was just one or two users but it transpired that over 80 users were affected!! After investigating whether or not ActiveSync was working as expected (it was) we turned our attention to looking at an issue within the users accounts.

It turned out that the 80 users were all a member of a protected group within Active Directory and weren't getting the correct permissions to sync their phones as per Microsoft's best practices.

In order to get to that stage I used some PowerShell queries which I thought were quite interesting so I'm sharing.

I used the following command to query Active Directory for all users that had the "AdminCount" attribute set to something greater than 0.  If set to 1 it indicates the user is either a member of a protected group or has been:

Import-Module ac* 

Get-ADuser -filter {admincount -gt 0} -Properties admincount -ResultSetSize $null | export-csv c:\\onyx\document.csv

To find out which groups within the Active Directory environment I was working in were considered a Protected Group I ran the following query:

Import-Module ac*

Get-ADgroup -LDAPFilter "(admincount=1)" | select name 

From there I was able to check the groups individually to see which ones contained, if any, the users that were having issues with their phones.  All the affected users were a member of the "Print Operators" group. Mystery solved!

Setup cannot continue with the upgrade because the “beremote()” process has open files.

I was applying a Service Pack to an Exchange server last week and came across this error message when running the setup wizard:

Setup cannot continue with the upgrade because the “beremote()” process has open files:

The server was being backed up with Symantec Backup Exec, this was causing an issue. I stopped the Backup Exec services and was able to continue with the service pack installation.

How to resolve the error ‘550 5.7.1 Unable to Relay’?

I recently came across an issue at work where one of our servers wasn't able to send any email alerts out. On troubleshooting the issue we were receiving a '550 5.7.1 Unable to relay' error message.

Duly checked the receive connectors within the Exchange Management GUI and everything looked okay but still the server wasn't able to relay. On launching the Exchange Management Powershell console we ran the command:

Get-ReceiveConnector "Receive Connector" | Get-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON"

And noticed that instead of there being rights for "ms-Exch-SMTP-Accept-Any-Recipient", there were rights for "ms-Exch-SMTP-Accept-Any-Sender"

We issued the command:

Get-ReceiveConnector "Receive Connector" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient"

And the server was able to relay messages once again. We haven't been able to determine, who or what changed the permissions on the connector but they'd been modified and the above command resolved our issue.

If you are trying to send notifications via your Exchange with an Anonymous connector ensure the following has extended rights:

NT AUTHORITY\Anonymous Logon {ms-Exch-SMTP-Submit}
NT AUTHORITY\Anonymous Logon {ms-Exch-Accept-Headers-Routing}
NT AUTHORITY\Anonymous Logon {ms-Exch-Bypass-Anti-Spam}
NT AUTHORITY\Anonymous Logon {ms-Exch-SMTP-Accept-Any-Recipient}