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”..


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


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



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:


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)


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.


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.


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


Job done! Any questions let me know.


Office 365 Tip: Use the Powershell to view or set the Mail attribute on a 365 User

I recently bumped into a very specific scenario, where i needed to view the mail attribute of a user on Office 365. And why did that happen?

In my scenario I was integrating (at the client level) Lync on Office 365 and Exchange on a completely different forest (not on the 365 tenant and not the on premises forest synced with 365). 

Therefore, my Lync Online user was not Exchange enabled neither on premises or on Office 365, because when that is the case then i really don’t see why you need to look at this specific attribute.

When you want to have client level integration between the Lync client and Exchange, the mail attribute (on the forest where Lync is – Office 365 on my scenario) for that specific user needs to be populated with the users email address.

So how can you populate that on premises? Open the Exchange Management Shell and run:

Set-User testvargas -WindowsEmailAddress testvargas@domain.com


Again this user DOES NOT have a mailbox or exchange attributes.

If you force Dirsync after this change, the mail attribute will be synced to Office 365. But how can you see if the attribute is there? Your first though might be, via the Windows Azure Active Directory Module for Windows PowerShell, by running a Get-MsolUser. Well that’s not going to show you what you need. If you run:

Get-MsolUser -UserPrincipalName User1@mydomain.onmicrosoft.com |fl *mail*

The output will be:


The reason you can’t see the mail attribute by running the Get-MsolUser is because that cmdlet will only show you the same attributes you can see via the Office 365 admin site, and not the entire set of attributes of the user.

Now let’s try and connect to the Office 365 Exchange Management Shell. User1 is not enabled for Exchange on premises or Exchange on Office 365. But that doesn’t mean that we can’t see what we are looking for, the mail attribute.

Connected to the Exchange Online Powershell, run the following cmdlet:

Get-User user1 |fl *mail*

Get-User user4 |fl *mail*


Important Note: I’ve ran the cmdlets against User1 and User4 to show you the differences. Both User1 and User4 do not have an Exchange Mailbox on premises or on Office 365. User1 had the mail attribute defined on premises, and pushed to 365 via Dirsync. User4 is a cloud user and we are going to define the attribute directly in the cloud. Again we are using the Exchange Management Shell on users that DO NOT have a mailbox on Office 365.

Finally let’s set the mail attribute on User4:

Set-User user4 -WindowsEmailAddress user4@domain.com

4So we’ve just use the Office 365 Exchange Management Shell to set the mail attribute for a user that does not have an Exchange Mailbox.

For me, the above procedures were fundamental when integrating, at the client level, Lync on Office 365 with Exchange on a completely different on premises infrastructure. There’s no point on giving more details about that, i will probably write a blog post, describing the entire integration process, one of these days.

Thanks and enjoy! 🙂