Enable-MailUser errors: “Exchange GUID is mandatory on User mailbox” & “Database is mandatory on User mailbox”

Not long ago I had to prepare an Active Directory to be synced with an Office 365 tenant. The company wanted to have Azure Active Directory Sync installed on premises, and sync all the users (and passwords) to Office 365. The plan was to use several of the Office 365 services, with of course Exchange Online included (it always is, right? ).

Because the company was using Azure Active Directory Sync, part of the preparation of the on premises Active Directory was to install an on premises Exchange 2013 Management Server (see here why should you keep at least one Exchange Management Server on premises when you are using AADSync), and to convert all users that will have a mailbox on Office 365 into mail users on premises, so that they can be manageable from the Exchange tools, and have all Exchange attributes. If you have a Hybrid deployment an Exchange mailbox user on Office 365 should be a Remote Mailbox object on premises, but if that is not the case (and for me it wasn’t) a mail user is enough.

Not let’s go straight to the problem I had and that is mentioned on this article title.

When I tried to enable all the users as mail users, I got the following error for almost all of them:

“Exchange GUID is mandatory on User mailbox”..

“Database is mandatory on User mailbox”..

1

So that got me thinking, and the first thing that came to mind was: What Mailbox? The users I am trying to enable as mail users are not mailboxes.

So I went and checked the users properties on AD, went to the attribute editor and find out that although all the users that I was trying to change were not mailboxes on Exchange, most of them had the msExchHomeServerName attribute populated with the LegacyExchangeDN of the server that was probably hosting their mailbox before it was disabled. Something clearly went wrong on the process of disabling those mailboxes in the past, and I needed to remove those attributes.

When I identified that attribute as the possible cause, the next thing I did was to remove that attribute from a single user, and tried to run the Enable-MailUser Exchange cmdlet only against that user. It worked, that was the attribute causing the issue. By the way I highly recommend that you follow the same approach and don’t go and remove an attribute for hundreds of users without making sure that it is the attribute that is causing you the issue.

One other thing that I need to stress here is that those users from which I removed the msExchHomeServerName attribute were NOT mailboxes on my Exchange on premises. DO NOT remove that attribute from production mailboxes!

Not let me tell you how I automated the process to remove the attribute from all my faulty users.

First I needed to have a CSV file with all the users that had the issue. In my case no user on premises had a mailbox, except my admin user, so all I had to do was take a full list of the users and exclude the admin before using the CSV to delete the attribute. On the Exchange Management Shell I ran:

Get-ADUser –filter * -Properties msExchHomeServerName | where-object {$_.msExchHomeServerName –ne $null} |ft userprincipalname, msExchHomeServerName

2

And to export the result to CSV:

Get-ADUser –filter * -Properties msExchHomeServerName | where-object {$_.msExchHomeServerName –ne $null} |Select-object Userprincipalname, msExchHomeServerName | Export-CSV C:\Scripts\UsersToChange.csv –NoTypeInformation

3

4

And again I can’t stress this enough, if you do have some mailboxes on premises you might want to either filter the CSV you get as an output or put an “-And” on the where-object statement above to exclude the mailboxes using an attribute that the users with problems don’t have (i.e msExchRecipientType)

Not that I had the CSV I needed a script to read from that CSV and delete that attribute on all the users with problems. I found this excellent script on the TechNet Gallery that removes Exchange Attributes using PowerShell. But the script had two problems:

  • It removed more attributes that I wanted/needed to
  • It prompted you to enter the users one by one, and I had hundreds

So I created king of a version 2.0 of the script, but to my own purpose of course, so that the script could read from the CSV and automatically remove the attributes from all the users in it.

See below the part that manners on the script, that you need to copy into a notepad and save as .ps1:

Write-host

Remove Exchange Attributes

—————————-

Remove Exchange 2013 Attributes for a Corrupted Active Directory Account

This Script will use a CSV as baseline

Caution : Mailbox Will Go Disconnected and Exchange Attributes will be Removed” -ForeGround “Cyan”

$AllAccounts = Import-Csv -Path C:\Scripts\UsersToChange.csv

foreach ($Account in $AllAccounts) {

$ADaccount = Get-User $Account.Userprincipalname

$FullDistinguishName = “LDAP://” + $ADaccount.distinguishedName

$AccountEntry = New-Object DirectoryServices.DirectoryEntry $FullDistinguishName

$AccountEntry.PutEx(1, “msExchHomeServerName”, $null)

$AccountEntry.SetInfo()

write-host “Changes made to account” $Account.userprincipalname

}

Make sure you edit the path and the file name of the CSV, and you are ready to run the script.

5

Once it’s done go to the user’s attribute editor on Active Directory and see if the value of the msExchHomeServer attribute is null.

6

And re run the Enable-MailUser Exchange cmdlet for all your users again.

7

Job done! Any questions let me know.

Advertisements

Office 365 Script: Enable users with a value on the mail attribute as mail users

When your Office 365 migration, is not from an environment where the mailboxes are on an Exchange On Premises (Hybrid/Staged/Cutover Migrations), and you’re are using Microsoft Dirsync to push your objects from the on premises active directory, into Office 365, then you need to prepare those objects on premises. That means that you should have users with the following attributes:

  1. A valid User Principal Name
  2. A Mail attribute
  3. Valid Proxy Addresses and ideally Exchange Attributes to be managed on premises

Regarding point 3, if like me, you’ve already done migrations from a 3rd party mail system to Office 365, with dirsync and just by adding a mail attribute to the users on premises, and pushing it into the cloud, you might ask, why should we have valid proxy addresses, and why should we have Exchange Attributes on those users? Well that is my opinion, and the way i work, and i will outline some reasons below:

  1. If the domain on 365 is federated, having the mail attribute will not be good enough, and you need to add proxy addresses, as described here. Enabling the users as mail users is a very quick and easy way of adding those proxy addresses, as opposed to having to edit those attributes on the Active Directory.
  2. Synced objects with Office 365 (Users, groups, etc) cannot have their attributes edited in the cloud. For example if you want to add an additional e-mail address to a mailbox on Office 365, and that mailbox is from a synced user, you will have to do it on premises and wait for dirsync to replicate those attributes to Office 365. There’s no better and easy way to edit those attributes than having those users enabled as Exchange objects on premises, and having an Exchange Server purely for management purposes.

The above does not mean in any way that your Exchange objects or your Exchange Server on premises will be part in any Hybrid Deployment. We are talking about migrations from a system which is not an Exchange on premises. The source can be Hosted Exchange, Lotus Notes, Google Mail, etc. And of course this scenario applies also when you have Dirsync.

Anyway I really highly recommend doing the described above, and to do that there’s sometimes a need to enable users as mail users. As a pre requisite I always ask my customers to prepare (or help them in the process, usually with scripting) the users with two important attributes: a valid User Principal Name and a valid mail attribute.

And once you have the two attributes above, and you want to enable those users as mail users, you can use the following script:

#This script enables users, on a specific OU, that have an e-mail address defined and are not exchange objects#
#This script is limited to the “TestAV” OU #
#Date:30/12/2014#
#Author: Antonio Vargas#

$users = Get-ADUser -SearchBase “OU=TestAV,DC=domain,DC=com” -Filter * -properties msExchRecipientTypeDetails, EmailAddress |where-object {$_.msExchRecipientTypeDetails -eq $null -AND $_.EmailAddress -ne $null}

foreach ($user in $users){
Enable-mailuser $User.UserPrincipalName -ExternalEmailAddress $User.EmailAddress
write-host $User.EmailAddress “<- This user was enabled as a Mail User.”
}

Now a quick example from my lab. I have 3 users on the OU being used by the script:

1

See below the output of the first part of the script, where it filters all the relevant users. User2 is the only one that does not have a mail attribute, and therefore was excluded from the output, which means that it will not be enabled as mail user by the script:

2

And when you run the script:

3

 

 

 

Finally you can see that both users are now enabled as Exchange Mail Users, and all your attributes, like the proxy addresses, should be in place. You can now manage those objects via your on premises Exchange Management Server.

This script should be executed on the Exchange Management Shell.

Again i very often bump into situations where my option is to execute a script like this one, and enable everyone as Exchange objects on premises, and if you are reading this post then probably that is also what you want to achieve.

Hope the above helped and as always any questions let me know.