Azure AD Connect: A quick way to check (online) the last time the sync ran

I was just doing some work in a devops work tenant, that usually has a Hybrid setup created and Azure AD Connect installed and running, and I realized that I needed to check when was the last time that:

  • the Directory synchronized successfully
  • Passwords synchronized successfully

As this is a very simple process I thought I should write a 5min blog post about it.

All you have to do is connect to the Azure Active Directory of your tenant and execute the Get-MSOLCompanyInformation.


The 3 parameters that you want to look at are:

  • DirectorySynchronizationEnabled (this one is not mentioned above. It shows if the tenant has the synchronization enabled or not)
  • LastDirSyncTime
  • LastPasswordSyncTime

Hope that this information is helpful.


Office 365: How to scope impersonation when migrating to and from Exchange Online

When you’re migrating to or from a Microsoft Exchange system, using an awesome tool like the BitTitan MigrationWiz, that leverages the Exchange Web Services (EWS) for the migration, you have 2 main options for administrator access to the mailboxes you’re migrating to and/or from: Impersonation and Delegation.

The best option depends on if the Exchange server is the online version (Office 365 multi tenant) or on premises. For Exchange on premises you should use delegation and for Exchange Online you should use impersonation. Why? Because you can’t create throttling policies in Exchange Online and impersonation is much less subject to throttling, when compared with delegation.

It’s important to understand that impersonation will also be subject to throttling, just not as much as delegation. When you’re migrating with delegation, all actions are done on behalf of the admin account, as opposed to when you’re migrating with impersonation, where actions are made on behalf of the account that is being migrated and impersonated.

Now that we can all agree that impersonation is the best authentication method for Exchange multi tenant systems (by the way this also applies to hosted Exchange systems outside of Office 365, but setting up impersonation on those systems might be somethings Hosters won’t do, unless they scope it, which they usually don’t), lets discuss the topic of this post: How can you scope impersonation? What exactly does that mean? And when will this be useful?

The answer for the first question is that you can scope impersonation by using management scopes and management role assignments.

As for the second question, scoping the impersonation rights means basically that the admin account will only be able to impersonate the accounts you define within that scope filter.

Finally the third question: this is useful when, for security reasons, you (or someone from the security team of the source or destination tenant) don’t want the admin account, that will perform the migration, to have access to impersonate all users in the tenant. This is a very common scenario in mergers, acquisitions and divestitures, where the admin user doesn’t need access to users that are not part of the migration.

Now lets translate all of this into a step by step guide of what you need to do, in order to scope impersonation in your Office 365 tenant.

Step 1: Create a distribution group

There are many different ways to apply a filter into a scope, and limit a management role assignment such as Application Impersonation, to a specific scope. I will teach you a simple way: via group membership.

You can create the group via the 365 management console or via the PowerShell. I recommend that you create a simple group as shown below (apologies, my current Office 365 tenant is in Portuguese, but I guess you can all recognize and understand the UI 🙂 ):


TIP: If you create this group just for the purpose of scoping impersonation, I recommend that you hide the group from the Global address list.

Now that the group is created, lets retrieve its DistinguishedName property:

Get-DistributionGroup -Identity AllowImpersonationDistributionGroup |fl name, dist*


Note: In the command above use your own Distribution group name, as you created it, or just run the Get-DistributionGroup without specifying the identity, and grab the DistinguishedName from the correct group (all will be listed).

Step 2: Create a Management Scope

Create a new management scope, use the “RecipientRestrictionFilter” parameter and the “MemberOfGroup” filter:

New-ManagementScope RestrictedMigrationScope -RecipientRestrictionFilter {MemberOfGroup -eq ‘CN=AllowImpersonationDistributionGroup,,OU=Microsoft Exchange Hosted Organizations,DC=EU


Note: To run the command above you might need to enable the Organization customization in your Office 365 tenant.

Step 3: Create the Management Role Assignment

Now that we have the scope created the last step is to create the management role assignment and associate it with the admin migration account:

New-ManagementRoleAssignment -Name:MyMigration -Role:ApplicationImpersonation -User:user10@ -CustomRecipientWriteScope:RestrictedMigrationScope


Note: In the command above use the scope name and the admin account that you are using for the migration. For my migration the admin is

And that is it, job done. Lets do some testing.

Below you can see users 1 to 5, that I will be migrating, and user10 that I will use as an admin.


Now looking at the group membership you can see that only user1, user3 and user5 are withing the scope, which means that user10 won’t be able to impersonate users 2 and 4.


Finally the result in MigrationWiz, in a project configured to use impersonation and with user10 as the source admin.


As you can see above, users 2 and 4 failed, and here’s the detailed error.


Bingo… MigrationWiz failed to impersonate at the source. Of course now that you read this that error will never happen to you!! 🙂

Happy migrations and as usual if you have any questions let me know.


The complete journey from Google to Exchange Online with Free/Busy rich coexistence

When questioned by partners, on what is the best approach to plan and execute a move of a customer’s email system, from G-Suite to Exchange Online in Office 365, the first questions that I ask are:

How many users do you have to migrate?

Are you going to do a migration in batches (Staged) or cut over all users at the same time?

Usually when there’s a large number of users, the migration in batches is the preferred option. At that point you should consider two things:

  • How can I automate the mail flow changes
  • How can I have free/busy coexistence between G-Suite and Office 365

The answer to both questions above is simple: You can automate the mail flow and have free/busy coexistence if you use BitTitan MigrationWiz to move the mailboxes, and the BitTitan automation processes to help you with the changes you need to do per migration batch.

In the past I wrote an article on how to configure mail flow coexistence between Google Apps and Office 365, that can help you understand the configurations you need to do.

BitTitan also has a very good article on how you can automate the mail flow changes, on a mail migration from Google to Office 365, as well as the entire migration guide.

But I want to focus this article more on the free/busy rich coexistence, between Google and Office 365, the value that it brings to your migration and your customer, a technical overview on how it works, and of course how you can configure it.

What is the value on having free/busy coexistence between G-Suite mail and Office 365 Exchange online

User experience. It’s all about the user experience!!! If you are moving a 20k users company from Google to Office 365, you often get questioned about what the migration journey will mean for the end users, in terms of end user experience. When you provide your customer and their end users the ability to have not only mail flow coexistence (that one is mandatory of course) but also calendar free/busy lookup capabilities, you’re giving them the best experience they can have.

I have also seen more and more companies using the BitTitan Google coexistence tool for permanent free/busy coexistence between G-Suite and Exchange Online, so don’t think about it just like an add-on to a migration project, it can be much more than that.

How can I achieve that with BitTitan

Currently BitTitan will allow you to use the Google coexistence tool for free during 3 months, if you use BitTitan MigrationWiz to move all of the mailboxes. If you want coexistence for more than 3 months, or if you’re not using MigrationWiz, you will be quoted a price per user per month.

Note: The statement above was true when I wrote this article. There no guarantee that will be true when you read it so please contNact BitTitan for more information.

Why do I need a free/busy coexistence tool between Google and Office 365

The answer to this is short and simple: the Google Calendar Interop, which is the tool that you need to configure on your Google tenant to query free/busy from Exchange mail systems, cannot query free/busy information, from an Exchange Online mailbox, via the Exchange Web Services API and the Availability Service. Instead it will try and query free/busy information from an Exchange Public folder. The problem is that the newer versions of Exchange don’t support that method anymore.

So in essence, because the Google Calendar Interop hasn’t evolved to match the changes that the Microsoft Exchange product group implemented in the way the free/busy is queried, specifically on the transition from Exchange 2010 to Exchange 2013, you need a translation tool between Google and Office 365. That translation tool is the BitTitan Google Coexistence tool.

How do I configure the BitTitan Google coexistence tool

The answer is, you don’t. You configure the Google Calendar Interop and Exchange Online by creating an Organization Relationship, both to point to the BitTitan Coexistence service, and you also create a MigrationWiz project in the BitTitan portal, so that you can obtain your authentication token from the BitTitan Support ( See here the coexistence setup guide.

This is how the Google calendar interop should look like:


And to configure the calendar interop:

  1. login to
  2. Go to Apps > G Suite > Calendar > Calendar Interop Management
  3. Enter all the information as per the coexistence setup guide

This is how the Exchange Online Organization Relationship should look like:


And to configure the Organization Relationship:

  1. Download the Coexistence script from the BitTitan setup guide
  2. Add the details to the script as per instructions on the setup guide
  3. Open an Exchange Online PowerShell session
  4. run the script
  5. Verify if the Organization Relationship was properly created by running: Get-OrganizationRelationship |fl

Do I need contacts in each organization for the free/busy to work

No, you don’t need a contact in Google for each user from Exchange Online that you want to query the free/busy, nor you need them in Office 365 for each Google user. You should have contacts in both sides, but to make sure you have a unified Global Address list.

To be clear on this:

  • is a Google mailbox
  • is an Office 365 mailbox
  • You don’t need to create as an Office 365 mail contact
  • You don’t need to create as a Google mail contact

But again.. you should.. having a unified GAL is usually mandatory and for sure highly recommended.

How do users query the free/busy information

As they do for any other internal user. They open their calendar app and enter the email address of the user on the other system or search for his contact created on the GAL if it exists.

To wrap this up, and please stay tuned for more blog post on this subject coming soon, the rich coexistence (mail flow and free busy) experience, when you’re migrating your customer from Google to Office 365, is very important and also very easy to achieve.

If you have any questions please feel free to reach out. I can help you understand it better as well as configure it.

As always I hope this post was helpful.

PS- The BitTitan coexistence tool also works between Google and Exchange 2010 Sp2+ on premises.





Office 365: Script to bulk change the UserPrincipalName to match the Email Address

When you are preparing your local Active Directory, to be synced with Office 365, one of the things you should consider is to make the UserPrincipalName of each user you are syncing to match the user’s email address. Why? Because that is going to be his UserPrincipalName and his primary SMTP address on Office 365.

So there are different ways of achieving this, some more manual than others. The procedure I am going to outline today on this blog post is a two step procedure:

Step 1: Export all UserPrincipalNames and Email Addresses from the local AD to a CSV File.

Step 2: Use that CSV file to bulk change the UserPrincipalNames to match those Email Addresses.

Like I said there are different ways of doing this, and I will probably develop a more elaborated script that can do this in a single step. The reason I went for this two step process is because most of the times customers want to check the CSV generated on step 1, and remove all the users that they don’t want to change the UPN, because those users will not be synced to Office 365.

Before we detail the steps above, make sure that you’ve added additional UPN domain suffixes for all the primary SMTP domains that you will have. See the article “How to add UPN suffixes to a forest” for more information.

Also have a detailed read on the article “Prepare to provision users through Directory Synchronization to Office 365”, to fully understand all the tasks you have to do to prepare your local Active Directory.

Making the UPN’s match the email addresses and have a domain that is validated on Office 365 is just one of the several tasks you have to do.

Now back to the two step process to change those UPN’s.

Step 1:

On step one all you have to do is open a PowerShell module on your local AD, and run the cmdlet below.

#Make sure you Import the Active Directory Module into your PowerShell session before you run the cmdlet

Import-Module ActiveDirectory

#Run the cmdlet to export all the users to a CSV. Change the CSV name and path as appropriate

Get-AdUser -Filter * -Properties UserPrincipalName, Name, EmailAddress | Select-Object UserPrincipalName, Name, EmailAddress | Export-CSV -Path C:\MyADUsers.csv -NoTypeInformation

After you run the cmdlet you should get a CSV like the one shown below:


On the example above you can see that the UserPrincipalName does not match the user’s email address, and therefore needs to be changed.

Once you get the CSV check all users that you want to change and remove from that CSV the ones that you don’t.

Step 2:

Now that you have the CSV with all the users you want to change, all you have to do on step 2 is run the script below. The script will change all the UPN’s to match the email address, based on the CSV file you will use.

#Script to Change the UPN on the Active Directory#
#This script should run from an Active Directory Module for Windows PowerShell#
#Version 1.0 – 06/30/2015#
#Author: Antonio Vargas#

$UserCount = 0

Import-Csv -Path C:\MyADUsers.csv | ForEach-Object {

$UPN = $_.UserPrincipalName
Write-Host “Working on user:” $UPN
Get-ADUser -Filter {UserPrincipalName -Eq $UPN} | Set-AdUser -userprincipalname $_.EmailAddress
$usercount = $usercount +1
Write-Host “Number of users on your CSV: $UserCount”
Write-Host “UPN’s Changed”

Copy the entire content above into a notepad, and save it as a .ps1 file.

The script above is a very simple script that will read from the CSV. Before you run the script make sure you import the Active Directory module, as described on step 1, into your PowerShell session.

I highly recommend running the script first against a small group of up to 5 users, and then make sure that the changes were applied successfully. Also you need to take into account that you are changing the UserPrincipalName of the user on your local Active Directory, so make sure to test the access to all internal systems that rely on AD for authentication, before you replicate the change to all of your users.

As always, if you have any questions please let me know.

Office 365: Script to get detailed report of assigned licenses

It’s very common to see Office 365 administrators asking in the community “How can I get a detailed report of the licenses i have assigned on Office 365?

Well it will depend on how detailed you want the report. I’ll detail here two solutions.

1 – Get a report of all licensed users and the AccountSKUId name

To run this report you need to open the Windows Azure Active Directory Module for Windows Powershell, and connect to Office 365. Once connected run the following cmdlet:

Get-MSOLUser -All | select userprincipalname,islicensed,{$_.Licenses.AccountSkuId}| Export-CSV c:\userlist.csv -NoTypeInformation

The above command lists ALL users and not just the ones that have a license. See the output CSV file below. There are ways of filtering the output (i.e export only licensed users), but i will keep this post simple. Let me know if you need something more elaborated.


2 – Get a detailed report of the licenses enabled for each user

One of the other requirements, is to know in detail, how many licenses per product do you have enabled, and which users have that license. If you want a detailed list with the users that have Lync Online, Exchange Online, Office Pro Plus (just to give three examples), or any other product that you have on your subscription, enabled or disabled, all you need to do is use the “Export a Licence reconciliation report from Office 365 using Powershell” script available on the Microsoft Gallery.

Again to run this report you need to open the Windows Azure Active Directory Module for Windows Powershell, and connect to Office 365.

Once connected to Office 365 browse into the directory where you saved the script, and run it.


The script will prompt you for the Office 365 administrator credentials, and run against all licensed users. By default the script creates a file named “Office_365_Licenses.csv” that will be created on the same directory where the script is. If you want, you can change it by editing the script. There’s also some other things you can change on the script, such as export all users and not just the licensed users, or use the existing credentials cached on your powershell session, instead of prompting you for credentials each time you run it. But again I will keep it simple for now, and if you want to change something on how the script works, let me know.

Now let’s have a look at the detailed output of the script.


Let’s now take the user Antonio Vargas as an example. He has all licenses assigned. Let’s see the view from the portal.


As you can see the Yammer licenses are assigned by default (hence the “PendingInput” state on the property exported to csv), and all other licenses are assigned, which matches with the success property on the csv. Now below let’s have a look at the user Calvin, which only has the Exchange Online license enabled (and the Yammer by default). All the other licenses are disabled.


Again when looking to the licenses that the user Calvin has assigned, via the Office 365 portal, it matches the csv file.

If you want, and because usually the output you will get is a very large csv file, you can use filtering at the csv level to get smaller lists depending on the license type you want the report on.

Any questions let me know, and happy reporting! 🙂

Apply RBAC on Office 365 based on a specific recipient attribute [custom recipient write scope]

Role based access control is the permissions model used in Microsoft Exchange 2013. Probably many of you are used to apply RBAC on your Exchange on-premises, based on custom scopes.

In Office 365 there are some limitations when applying scopes to RBAC, such as the Organizational Unit scope. On this post we are going to create a Management Scope based on the custom recipient write scope, and create a Role Group that uses that management scope. What is the main goal? Well in this scenario the main goal is:

Give permissions to specific Help Desk administrators to manage only recipients that have the Department mailbox attribute set to “IT Department”. The administrators added to that role group should not be able to manage any other users.

Note: RBAC customization is not available on all Office 365 plans. To make sure that your plan has RBAC customization see the Exchange Online Service Description.

So let’s get started. The first thing I did was to create 4 users on my Office 365 environment, named User1, User2, User3 and User4. Those 4 users work on the IT department. I also created a user called HelpDeskUser. I want Helpdesk user to be able to manage only the users on the IT Department, in this case User1, User2, User3 and User4. The HelpDesk user is not a member of any other Role Group.

All the users have a license assigned and a mailbox on Office 365.

After the user creation I needed to populate the Department attribute on User1 to User4 mailboxes, because that’s the attribute i am going to use on the custom recipient write scope. You can do this in two ways, via the Office 365 Admin Portal or via the Windows Azure Active Directory Module for Windows Powershell.

To do it via the portal, you need to click on “Users > Active Users”, select all the users you want to add the attribute to (you can filter before selecting), and click on “Edit”.


On the Details page populate the Department attribute, as shown above, and click “Next”. If there’s nothing else you want to change, click “Next” on the other pages and click “Submit” on the last one.

To do it via the Windows Azure Active Directory Module for Windows Powershell, start by connecting into the Azure AD as an Administrator (Connect to Azure AD). Once connected, run the following cmdlet to filter the users you want to change the department attribute:

Get-MsolUser -All |where-object {$_.Userprincipalname -like “User*”}

In the cmdlet above I’ve filtered all users with a Userprincipalname that starts with User. You need to adjust the filtering to your specific case.

Once the filtering is returning the expected users, run the following cmdlet to set the department attribute on those users:

Get-MsolUser -All |where-object {$_.Userprincipalname -like “User*”} |Set-MsolUser -Department “IT Department”

To check if the cmdlet applied the attributes successfully run:

Get-MsolUser -All |where-object {$_.Userprincipalname -like “User*”} |fl Userprincipalname, Department


Above you can see the output of all the cmdlets.

Note: In my environment I did the changes on cloud users, as i am not using Dirsync. If you are using Dirsync, and if the users you are changing are synced users, you should make the changes on-premises and force Dirsync (or wait for it to run) to push the attributes to Office 365. Then you can run the last cmdlet shown above to check if the attributes were replicated to Office 365

Once the attribute is defined on all users, we can start configuring RBAC on Exchange Online.

The RBAC configuration is done in two steps:

  1. Create a Management Scope
  2. Create a Role Group

To create both you need to open a powershell and connect it to Exchange Online.

Once you are connected to Exchange Online you can start configuring RBAC. I started by running the following cmdlets, to list all my current Role Groups and Management Scopes:



3As you can see above, I only have the custom role groups and i have no Management Scopes created.

So now let’s create the Management Scope. The scope will have a recipient filter, and one of the questions that I get a lot is, “How do we know if this filter is accurate?”. Well the answer is simple: Test the filter before creating the scope, by using the “Get-Recipient -Filter” cmdlet. To test my filter i ran the following:

Get-Recipient -Filter {Department -eq “IT Department”}


My filter is returning the exact users I want to apply the scope to, so i can now create the Management Scope, by running the following:

New-ManagementScope “HelpDesk for IT Users” -RecipientRestrictionFilter {Department -eq “IT Department”}

With the command above i created a management scope named “HepDesk for IT Users” with a recipient restriction filter for all users with the “IT Department” value on the “Department” attribute.

Note: To create a new management scope you might need to run the Enable-OrganizationCustomization cmdlet first. If you don’t you might get an error, as shown below.


Once the management scope is created we can create the Role Group. Just as when you created the management scope, to create the role group you also need to be connected to the Exchange Online powershell, and run the following cmdlet:

New-RoleGroup -Name “HelpDesk IT Department” -Roles “Mail Recipients”, “Reset Password”, “Distribution Groups”, “Mail Recipient Creation” -Members “HelpDeskUser” -CustomRecipientWriteScope “HelpDesk for IT Users” -ManagedBy “Organization Management”


The command above will create a role group named “HelpDesk IT Department”, with 4 roles that will allow it’s members to manage mailboxes and distribution groups, add the “HelpDeskUser” as a member of the group, assign the previously created management scope to the group, and make it managed by the members of the “Organization Management” role group. For more information on which roles you should assign to your role group, click here.

On the Exchange Online Admin Center you can see the new role group, and if you select it, on the right pane you can see the roles, members and write scope assigned to it.


So once that is done… it’s job done!!! 🙂

But, lets do some testing, shall we?

Start by logging into Office 365 with the admin account added to the group, by going to

Try and edit the Organization properties of a mailbox outside of the scope. You should see that the properties are grayed out, which means that the settings applied correctly and you can’t change it.


Now let’s try and edit the Organization properties of a mailbox from the IT Department. You should see the properties available for editing.


So the Role Group is configured correctly.

Job done.. and tested!

Script to assign Office 365 full access permissions based on the MigrationWiz bulk import CSV file

When you’re migrating to Office 365 using a tool like MigrationWiz, one of the requirements should be to have a “MigrationWizAdmin” account, on Office 365, that will have full access to all the mailboxes (unless you want to specify each user’s password when importing the users to the MigrationWiz project).

Most of the times the “easy” solution is to run the following cmdlet:

Get-Mailbox -ResultSize unlimited | Add-MailboxPermission -User -AccessRights fullaccess -InheritanceType all -AutoMapping $false

And you can also use the “Filter” parameter on the “Get-Mailbox” to narrow the number of mailboxes where the MigrationWizAdmin will have full access, based on one or several specific attributes, as show below:

Get-Mailbox -ResultSize unlimited -Filter {(RecipientTypeDetails -eq 'UserMailbox') -and (Alias -ne 'Admin')} | Add-MailboxPermission -User -AccessRights fullaccess -InheritanceType all -AutoMapping $false

The cmdlet above filters all user mailboxes, excludes the one that has the Alias “Admin”, and assigns full permissions to the migrationwizadmin user.

So could this solution fit the requirements of all your scenarios? Not really. Why? Some of the reasons are outlined below:

  • If you’re moving a subset of users to an existing tenant (i.e on a company acquisition), giving full permissions to the MigrationWizAdmin on all online mailboxes might just not be an option. Why should you give full access permissions on an existing Office 365 mailbox that is not going to be migrated? You should have a plan B.
  • Filtering might be a good option, but you need to set specific and unique attributes on the Office 365 mailboxes that are going to be migrated, and in most cases that just doesn’t happen.

So what could be your plan B? Well if you’re familiar with the MigrationWiz process, you know that after creating the project, the next step would be adding the users/items. You have several options to add them, such as using autodiscover, bulk add users via a CSV file or manually add each user.

I normally use the CSV file. To download it you have to choose the “Add > Bulk Add” option on the project, and click on “Download sample CSV file”.


Then all you have to do is, export the e-mail addresses from your source system, copy them into the MigrationWiz CSV and import the CSV via the portal.

Now, can i use that CSV file to assign permissions to the Office 365 mailboxes? Yes, and by using the CSV file you will be assigning permissions only to the users you’re going to migrate.

I’ve built a small and simple script that will read the “Destination Email” column and assign permissions to all the users on the CSV. You can copy and paste the script into a notepad and save it as a “.ps1” script. You need to connect to the Exchange Online management shell to run the script. Click here for guidance.

#Script to add mailbox permissions on Office 365 to an admin account#
#This script should run from an Exchange Online Management Shell#
#Version 1.0 - 27/05/2014#
#Author: Antonio Vargas#

foreach ($user in Import-Csv "C:\BlogTestDir\migrationwiz_import.csv"){ 
 Get-MailBox -Identity $user."Destination Email" |Add-MailboxPermission -user -AccessRights FullAccess -InheritanceType All -AutoMapping $false
 write-host "Permissions added for the mailbox:" $user."Destination Email"


Replace the user “” with your Office 365 admin MigrationWiz admin user.

Note: The Office 365 MigrationWiz admin user, that will have full access on the destination, to all mailboxes being migrated, needs to be mailbox enabled.

Now see below an example of the CSV file, and the output of the script based on that file.



Finally if you want to check if the your admin user has full access on a specific mailbox, you can run the following cmdlet:

Get-MailboxPermission -Identity -User


This blog post and the script can be useful to things as simple as giving permissions on mailboxes (on premises or on Office 365) based on a CSV file, or more specific such as during a MigrationWiz project.

Thanks and ping me if you have questions! 🙂

Office 365: Quick tip to list users with “” UPN due to invalid on premises configuration

Imagine this scenario: You are doing a migration to Office 365, with Microsoft Dirsync, but you’re not the one preparing the on premises Active Directory. Someone else is doing that work and dedicated to the local AD.

You tell them that all users to be activated on Office 365 need to have a vanity domain as their User Principal Name (e.g They prepare the Active Directory, you install and configure Dirsync and you do the initial sync. Now you want to make sure that no user got the username due to an invalid configuration on premises.

Note: If the UPN of the user on premises has a domain that is not validated on Office 365, the username on 365 will be the

What should you do? Well, in those cases what i do is, i list all the * usernames, export it into a .csv file, and send it to the Active Directory team for validation. The question should be: “Do any of the listed users need to be activated on Office 365, and therefore need the UPN fixed on premises?”

To build that list is quite simple. First you need to open the Windows Azure Active Directory Module for Windows Powershell, and connect to your tenant, by running the following cmdlets:

$msolcred = get-credential
connect-msolservice -credential $msolcred

See detailed instructions here.

Once connected, to get a list of all the users with an * username, run the following cmdlet:

Get-MsolUser |where-object {$_.UserPrincipalName -like "*"}

The output of the cmdlet above should be:


If you want to know the total number of users with the * username, run the following cmdlet:

(Get-MsolUser |where-object {$_.UserPrincipalName -like "*"}).count

The output of the cmdlet above should be:


Now, to export those users to a .csv file, run the following cmdlet:

Get-MsolUser |where-object {$_.UserPrincipalName -like "*"} | Select-Object Userprincipalname, Displayname, Islicensed | Export-Csv C:\Test\UsersWrongUPN.csv -NoTypeInformation

You will get a csv file, like the one shown below:


On the .csv file you will probably see users like the tenant admin, or service accounts. The tenant admin is a cloud user and doesn’t need to have the username fixed on the on premises Active Directory. The service accounts might be irrelevant also, and to prevent them from showing on Office 365 your solution would be to use OU based filtering on Dirsync. See here how.

All you have to do now is send the .csv file to your Active Directory administrators and have them validate the users that need fixing, the users you can/should filter to exclude from being synced to 365, and the users you can ignore and keep them with an * username.

Again this is particularly useful when you’re not the one preparing the Active Directory for your Office 365 deployment.

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 #
#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:


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:


And when you run the script:





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.

Office 365 & MigrationWiz: “ErrorNonExistentMailbox: The SMTP Address has no Mailbox associated with it”

Just a few days ago i was using MigrationWiz to push a customer from a hosted Exchange to Office 365. Usually when there’s no possibility of building a Hybrid Deployment, in cases when the source system is a hosted Exchange or a 3rd party e-mail platform, i recommend and use MigrationWiz as the tool to migrate the mailboxes data into Office 365, as it’s an excellent tool and easy to use, which is very handy because we tend to offload the bulk migration of the users to the customer’s IT department.

But back to the problem i encountered. As i usually do, i have configured an administrator account on the source (Hosted Exchange) and one on the destination (Office 365). Both of those administrator accounts had full access permissions to all mailboxes. I configured a connector, to use those accounts, and added some test mailboxes to the connector to start moving data and see if everything was OK. My admin account on the source was and i added that account to the connector as well to migrate the data, as a test. Once i started the migration i got the following error:

Your migration failed checking source credentials. The SMTP address has no mailbox associated with it. Error: ErrorNonExistentMailbox Detail: SmtpAddress

Well i was sure that the source mailbox existed as i was able to log into it via Outlook Web Access, so what was the problem?

The answer is actually quite simple. MigrationWiz uses Exchange Web Services (EWS) to perform the moves of the mailboxes, and the reason is better throughput!! 🙂 Read more about the MigrationWiz performance on the below link:

But again back to the problem. Those MigrationWiz EWS queries will fail if the mailbox is hidden from the Global Address List. And that was my case. Why? Well for starters you might want to hide from the global address list on the source (and even the destination), a mailbox which is in fact only used for migration purposes.

The solution? Disable the hide from address list option on the mailbox and you’re sorted.

One thing i do recommend if you’re looking at an error just like the one i have is, make sure that the mailbox actually exists. Try logging into the mailbox using Outlook Web Access. Or else you might be chasing ghosts! 🙂

I hope this post was helpful.