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 email@example.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 firstname.lastname@example.org
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! 🙂