Office 365 Public Folders Migration: Why and when to use MigrationWiz and not the Microsoft native tool

Migrating legacy Microsoft Exchange Public Folders to Office 365 is a challenge that many Organizations are facing at the moment, and the first question that comes to mind is: “What tool shall I use?”

From my perspective and experience, you have two valid options to push your Public Folders to Exchange Online:

  1. The Microsoft Native tool
  2. MigrationWiz from BitTitan

Reasons to use the MigrationWiz Tool

When the source is a Hosted Exchange

Most of the steps you need to follow on the Microsoft TechNet article, to migrate the legacy public folders to Office 365, require full control on the source system. No Exchange hoster will give you the control and permissions you need to use the Microsoft Native tool, therefore using MigrationWiz will be the best option in this scenario.

When the source is Exchange 2013

Microsoft states the following, on the official technet article:

“Exchange supports moving your public folders to Office 365 and Exchange Online from the following legacy versions of Exchange Server:

  • Exchange 2010 SP3 RU8 or later
  • Exchange 2007 SP3 RU15 or later”

This means that when the source is Exchange 2013, at the moment there is no official and supported migration path to move the public folders to Office 365, as you can also read on the BitTitan’s blog article, that describes the experience of the Microsoft Exchange expert and blogger Todd Nelson.

Because you don´t need to patch your existing Exchange Servers

As described above, and stated by Microsoft, to run the native tool your source servers need to be patched with at least Exchange 2010 SP3 RU8 or Exchange 2007 RU15. Patching Exchange servers might require downtime, and if you´re moving to Office 365, chances are you will decommission all Exchange Servers, keeping only one for management if you are using AADSync. So why schedule a maintenance window and patch servers there are soon to be decommissioned? MigrationWiz supports major versions with no specific requirements on the service pack or update rollup.

Support for large Public folders

MigrationWiz adds great value, when you have large individual public folders, and/or the total amount of public folder data to be migrated is very large.

But let’s start with the individual public folders. Microsoft clearly states the following, on the native migration TechNet article:

“Before migration, if any public folder in your organization is greater than 2 GB, we recommend either deleting content from that folder or splitting it up into multiple public folders. If either of these options isn’t feasible, we recommend that you do not move your public folders to Office 365 and Exchange Online.”

Which means that they do not support the migration of public folders larger than 2GB, or at least if and when you have a problem with your migration (and believe me, chances are you will), related to folders bigger than 2GB, the Microsoft support will probably give you an answer based on the statement above.

By default the Public folders on Office 365 cannot be larger than 2GB, but as you can see on the Public Folder limits Technet article, that limit can be extended up to 10GB. If you have public folders with more than 2GB (and of course less than the 10GB limit), all MigrationWiz requires is that you prepare your target environment, by following this article.

Regarding the large total amount of data to migrate, the great value of the MigrationWiz tool, when compared to the native tool, is the capability of, in case of error, getting more detailed information, and more importantly, not having to restart a migration. I was forced to restart very big migrations, done with the Microsoft Native tool, after getting very vague errors, and because the Resume-PublicFolderMigrationRequest was not working, to get my failed migration back in motion. As you can imagine having to restart a 400GB Public folder migration that was 50% done, it´s not a good experience 🙂

1

As you can see on the example above, the errors on the MigrationWiz portal are very clear and detailed, which helps a lot when troubleshooting. Public Folder mailboxes in Office 365 have a limit of 50GB per mailbox, therefore, if you´re migrating more than 50GB of data you need to follow this MigrationWiz article.

More details and statistics during the migration

Although with the native tool, you can run a Get-PublicFolderMigrationRequestStatistics, with the “-includereport” option, and export it to csv, that is nothing compared to what the MigrationWiz portal provides you.

2

You can see both the total number and size, per item type, with errors or migrated successfully.

3

There’s also information on the data migrated, items migrated or transfer speed, for you to have a better understanding of how things are progressing and estimate total migration times.

4

You can see the migration history, and all kinds of statistics, including a very useful data and item speed per hour statistic.

All the above is, in my opinion and based on my experience, very important when you are migrating a large amount of data.

It´s easy to migrate

The way I see it, unless you have very good technical knowledge of both Exchange online and on-premises, you should go for a tool like MigrationWiz that makes your life much easier.

I’ve seen a lot of issues when using the Microsoft Native tool (and you can find some posts in my blog on how to solve them), and if you don’t have advance knowledge, and you want to use the tool, you should find someone that has that knowledge and experience, and can assist you with the migration.

To be clear:

Is the Microsoft native tool, to migrate public folders, a good tool? Yes!

Does it work? Yes!

Is it challenging from a technical perspective? Yes!

Reasons to use the Microsoft Native Tool

If none of the above is relevant to you or your Organization, and you are an expert on Exchange online and on-premises, then you can use the native tool.

The bottom line is that, everything I stated on this post is based on the large experience that I have with Office 365, and more specifically with migrating Public Folders to Exchange Online. I´ve helped dozens of Organizations to achieve that, and learned a lot in the process.

I hope this post was helpful and as always, let me know if you have questions!

MigrationWiz: Public Folder migration fails to check destination credentials “No Public folder mailbox found” error

Are you trying to migrate your Public Folders to Office 365 and getting the error below?

1

Of course the first thing I recommend is obviously for you to check if you do have Public Folder mailboxes created in your Office 365 tenant. Log into the 365 portal, click to Admin Exchange, and then go to Public Folders > Public Folder Mailboxes.

4

You might need to wait up to 5/10 minutes after you create the Public Folder mailboxes and before running the MigrationWiz Public Folder project.

Also please make sure your MigrationWizAdmin user has the necessary permissions on the Public Folder structure. Read here for guidance.

Now what if everything described above is configured correctly, and you still have the same “No public folder mailbox found” error? Of course all the configurations described above are mandatory, but the real reason for this post is that something else might cause this error.

If all your users were moved to Office 365, and are accessing the Public Folders on premises, before you move those public folders to Office 365, I am sure you followed the Microsoft official article “Configure Legacy on-premises public folders for a Hybrid deployment“.

To enable the access to the legacy public folders, amongst other things, you need to run the following cmdlet:

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMailbox1,PFMailbox2,PFMailbox3

What the above cmdlet will do is, at the organization level set the Public Folders to remote, and more importantly, by setting the “RemotePublicFolderMailboxes” parameter and the OrganizationConfig level, it will change the “DefaultPublicFolderMailbox” parameter at the mailbox level, for all user mailboxes.

2

Above you can see that the RemotePublicFolderMailboxes is set to a mailbox called admin.vargas, and in your scenario it should be the name of an on premises mailbox, “dirsynced” to Office 365.

3

And if you look at the DefaultPublicFolderMailbox on your users, including the MigrationWiz admin user, that value will be set for the on-premises mailbox setting to match the “RemotePublicFolderMailboxes” parameters on the Organization Config.

So how does this affect the MigrationWiz project? Simple. Looking at the example above, the DefaultPublicFolderMailbox of the migwizadmin user is an on-premises “dirsynced” to 365 mailbox named “Admin.Vargas”, and that causes MigrationWiz to assume that there is no available public folder mailbox on 365. The solution is simple. Run the following cmdlet on your Office 365 Exchange PowerShell:

Set-Mailbox -identity migwizadmin@domain.onmicrosoft.com -DefaultPublicFolderMailbox PFMBX

4

You can see your Public Folder mailbox name, on your Office 365 Exchange Admin Centre, as shown above.

5

The cmdlet and the output, from the Exchange Online PowerShell.

Once the change is made, retry the MigrationWiz project, and job done!

There are a lot of good reasons for you to be in the scenario described above – Using MigrationWiz under a hybrid scenario, to move your public folders to Office 365 – especially if you have Public Folder with more than 2GB and a total amount of Public Folder data of more than 50GB. I will soon blog about all the advantages of skipping the Microsoft native tool to migrate the public folders and using MigrationWiz. Stay tuned!

Yet another Exchange legacy Public Folders replication issue: Old content not replicating to new PF databases

If you´re reading this post, chances are you´re stuck with a public folder replication issue. I´ve seen all sorts of issues with the replication of legacy public folders, but none without solution, so hopefully your solution is here 🙂

My scenario:

  • Exchange 2010 Service Pack 2 in 3 servers (2 existing and 1 new)
  • CAS/HT/Mailbox roles on all servers
  • Each server has a public folder mailbox
  • One server in Asia, one in America and one in the EMEA region

My problem:

The new public folder database was not getting all the existing public folder replicas/content.

Instead of going direct to my issue, let me guide you through all the steps you should take to make sure you understand why your replicas are not being pushed to the new PF database:

Have you added all the replicas (or the ones you need) to your new public folder database?

AddReplicaToPFRecursive.ps1 -Server <ExistingServer> -ServerToAdd <NewServer> -TopPublicFolder “\”

AddReplicaToPFRecursive.ps1 -Server <ExistingServer> -ServerToAdd <NewServer> -TopPublicFolder “\NON_IPM_SUBTREE”

The script above is on the Exchange scripts folder, and can be ran from an Exchange Management Shell. Look here for more details on the script.

You can check which replicas a public folder has, by running:

GetPublicFolder -Identity ‘\’ –Recurse | fl Name, Replicas

Get-PublicFolder -Server <NewServer> -Recurse

Is the above done and your public folder database is still not up to date?

If you do have the replicas pushed to the new server, and the content is still not being replicated, then please also check if the mail flow between the source and destination server is working.

In my case of course it was working, because as stated on the title of this post, only the old content of the public folders was not being replicated. New content was fine, which means that issues like mail flow or invalid replicas were ruled out.

An example:

UserA was connecting to a database on the new server that was using the new public folder database. Via OWA UserA opened the Public Folders, and created a new item. The item was replicated to all the Public Folder databases on all servers. UserA can only see a very limited number of items on the Public folders, all recent and created after the creation of the new PF Database.

So lets take a closer look at the statistics of a specific folder:

pferror1

The Public Folder “US” had zero items in the new server and 1087 on the old one. An item created now would replicate to both the new and the old server, but nothing was happening to old content.

Now before I continue, it´s mandatory for me to recommend you read an excellent Public Folder Troubleshooting article from the Ehlo Blog.

The next step is to raise the event log level on both the new and the old server. The logs you need to set to expert are under the “MSExchangeIS > 9001 Public” and are named “Replication Incoming Messages” and “Replication Outgoing Messages”.

pferror2

Now let’s force an update on a public folder by running on the new server Exchange Management Shell:

Update-PublicFolder -identity “\US” -server <OldServer>

And on the new server event viewer you can see the 0x20 Status Request event (see the troubleshooting guide provided above for more info on event codes).

pferror3

On the old server you can see the status request reply:

pferror4

But what you never see is an event like the one below, with status 0x4 that indicates that content is being replicated.

pferror5

So what is the solution? Update all the content using the ExFolders tool.

Click here to download it, and for full instructions on how to run it.

Once you have the Exfolders opened and connected to the old server, select the folders you want to update (in my case I selected the route because I wanted to update all) and click on “Modify All Items”.

pferror6

IMPORTANT NOTE: This will cause a replication storm, which means that all public folders on all databases will be updated and replicated. If you have a large public folder infrastructure you might want to consider doing this procedure during off work hours.

You will then see the folders being updated.

pferror7

And once that is done, wait for the replication to take place and run the public folder statistics cmdlet again.

pferror8

All up to date!

Hope that the above was helpful..

Set-AzureStaticVNetIP Error: The static address doesn’t belong to the address space defined by the role´s subnet

Quick blog post on a simple and logic error that you might get when you´re trying to set a static IP on your Microsoft Azure VM.

1

So as you can see above, when you try and run:

Get-AzureVM -ServiceName MYMSEXCHANGE -Name TestVNetVM |Set-AzureStaticVNetIP -IPAddress 192.168.0.150 |Update-AzureVM

You get the error:

“Update-AzureVM : BadRequest : The static address 192.168.0.150 doesn’t belong to the address space defined by the role’s subnets.”

The reason behind this error is simple: You are trying to set a static IP for your VM that does not belong to the subnet where the VM is. So let’s have a quick look on how to see which subnet does your VM belongs to. From the azure PowerShell run:

$MyVM = Get-AzureVM -ServiceName MYMSEXCHANGE -Name TestVNetVM

Get-AzureSubnet -VM $MyVM

2

The output will show you the Subnet of your VM.

You can also see the network where your VM is on by running:

Get-AzureVM |fl Name, VirtualNetworkName

4

Now that you know what network and subnet your VM is on, you can go to the Azure Portal > Networks, and on the Configure tab of the network you can see the range of IP addresses from the subnet of your VM:

3

In my case the VM is on the subnet-2, with a range of Ip’s of 192.168.1.0/24 and i was trying to set up an IP address on the 192.168.0.0/24 range.

Let’s try with a valid IP now on the 192.168.1.0/24 network:

5

No error, job done, and as simple as it gets! 🙂

Microsoft Azure Tip: How to assign a static IP address to your Azure VM

This blog post will quickly show you how you can assign a static IP address to one of yours Microsoft Azure Virtual Machines, using the Microsoft Azure Powershell.

Assuming that you have already created at least one virtual machine, on your Azure subscription, the first thing you need to know and do is, how to install and configure the Azure Powershell.

On the article from the above link, you can follow the instructions to install the Microsoft Azure Powershell and to connect it to your Azure subscription.

Now let’s login to the Microsoft Azure Management Portal, and start by looking at the Virtual Networks.

Network-VM-1

I created a virtual network on my subscription, named “vlan192”, and as you can see the virtual machine “DC01” got the IP address 192.168.0.4 assigned, which is part of a sub. Now I will change that IP address to one of my choosing.

Network-Subnets-2

Above you can see the virtual network in more detail. Before assigning a static IP address to your virtual machine, make sure the address you choose is within the usable address range of one of the subnets of your virtual network. My virtual network has two subnets.

One other thing that you need to take into account, is that when you create the Vitual Machine, you need to make sure that you assign the correct virtual network and subnet to it, as shown below:

Network-createVM-3

You can always go to the Dashboard of the virtual network, and make sure that the Virtual Machine you created is listed there, and what subnet is the virtual machine using.

We can now connect to the Microsoft Azure Powershell and set the static IP. Let’s start by running the following cmdlet to see the details of the existing virtual machines:

Get-AzureVM

The cmdlet above will give you the servicename and the virtual machine name that you need to run the cmdlet that sets the static IP:

Get-AzureVM -ServiceName <ServiceName> -Name <VMName>  | Set-AzureStaticVNetIP -IPAddress <StaticIP> | Update-AzureVM

Below you can see the output of the cmdlet.

Network-changeIP-4

And finally if you go to the properties of the virtual machine, on the Azure Management Portal, you can see that the static IP is set.

Network-checkIP-5

IMPORTANT NOTE:

You need to be aware is that the IP above is assigned to the specific VM. A reservation is made and therefore that will be the IP of the virtual machine as long as the reservation is kept. This does not change the network properties at the OS level. It doesn´t set the static IP there. You should now login to the virtual machine and set the static IP to match the reservation, as you are now sure that it won’t cause any IP address conflict.

Office 365 tips: Automatic DNS records creation when your custom domain is hosted with GoDaddy

Last week I started another Office 365 project. The custom domain to validate is hosted with GoDaddy, so once more I took advantage of the excellent integration feature between Office 365 and GoDaddy.

This feature is not new, but it’s very good and therefore always worth blogging about it.

Click here to see the official statement from Microsoft, about this integration, and a demo video.

Now a quick walkthrough. My domain was already validated, but you can use the integration also for the domain validation, as it creates the necessary DNS record.

After the domain is validated and you set the domain purpose, the Office 365 Admin portal detects that your domain provider is 365, and you can then click on “Add Records” to add your DNS records.

1

Before adding them, you can see the detail by expanding “View the DNS records we’ll add”.

2

A GoDaddy logon window will pop up. Enter your username and password.

3

Click confirm to accept the changes on your public DNS zone.

(Note: Apologies about the Portuguese screenshoots)

4

You will then get the confirmation that the changes were done.

5

And if you login to your GoDaddy account and edit the zone file for your domain, you will see all the new DNS records there.

6

That’s it. As simples as that! Enjoy!

Office 365: How to enable federation on your Lync Online Organization

Have you just started using Lync on Office 365, and when trying to federate with someone on another company, or when they try and federate with you, all you/they see is “Presence Unknown”? Continue reading through all the steps to enable federation on your Lync Online Organization.

The first thing you need to do, is to make sure that all the necessary DNS records are in place. Go to your Office 365 Admin Portal, click on Domains or the left hand side, and you will see all of your domains. Lync uses the UserPrincipalName of the user to set the SIP address, which means that your SIP domain will be the one used for the UPN also (and btw it should also match your primary e-mail address). Select the domain and click on “Manage DNS”.

1-1

Make sure the domain purpose is set for Lync Online.

1-2

Make sure all the Lync Online DNS records are created on your public DNS zone. You can check which records you need to create also on the Manage DNS section.

3

Now let’s have a quick look to see if the records are in place. We will check specifically the SIP federation SRV record, but i recommend you check them all. Open a command prompt and run:

nslookup -q=SRV _sipfederationtls._tcp.yourdomain.com

1-3

As you can see it points to sipfed.online.lync.com

Now that we know that all the DNS records are in place, go to your Office 365 admin portal and click on “Admin > Lync”

4

Why is this a required step?

Because the Lync Online Federation comes DISABLED by default

To enable it, on the Lync Online Admin Center, click on “Organization” and on the right hand side, click on the “External Communications” tab.

1

You will see that the external access is defined to “Off completely”. Change it to “On except for blocked domains” or “On only for allowed domains”. You can also turn on or off the public IM connectivity, and below you can define all the domains to allow or block.

2

And that’s it, job done. Don’t forget if you just enabled your Lync online tenant you need to allow federation, as it comes disabled by default. And make sure the DNS records are in place!

Exchange Active Sync on-boarding to Office 365 – The seamless experience is finally here

For those who are thinking on moving to Office 365, and in what that might mean from a user experience perspective, the release of the Exchange 2013 Cumulative Update 8 (CU8) and Exchange 2010 SP3 Rollup Update 9 (RU9) brings a long expected feature – seamless experience on the on-boarding process of ActiveSync users, to Office 365.

You can read the full details on the article Exchange ActiveSync on-boarding to Office 365, published on the Exchange Team Ehlo Blog.

Instead of duplicating all the information that you can read on the official blog article, i will just give you my thoughts on how this works and highlight the key points.

When a user is moved to Office 365, under a Hybrid deployment, that mailbox on premises is converted to a remote mailbox, and a “RemoteRoutingAddress” of the type User@tenant.mail.onmicrosoft.com is configured for the remote mailbox.

That remote routing address should be configured as a domain name on an existing Organization Relationship “On premises to O365”.

Before Exchange 2013 CU8 and Exchange 2010 SP3 RU9, the experience was only seamless for users via Outlook or OWA. When those users, moved to Office 365, tried to connect to the Client Access server on premises, a mailbox wasn’t found.. so what happened next?

“The Client Access server triggers a query to find the “TargetOWAURL” property present on the organization relationship object for the Office 365 tenant. The “RemoteRoutingAddress” property, present on the remote mailbox, is used to find the correct organization relationship.”

That “TargetOWAURL” is then used by Outlook (automatically reconfigured the profile) or OWA (presents the new URL to the user) to redirect the user to the Office 365 mailbox.

After Exchange 2013 CU8 and Exchange 2010 SP3 RU9, that process will also work when the user is connecting via Exchange ActiveSync, making the experience seamless as well for all the ActiveSync users.

Of course for all of you that, like me, spend countless hours explaining to customers that recreating the exchange partnership on all of their user’s phones, was the only option, and helping on the creation of user guides, this new feature is excellent news.

From my personal perspective it makes perfect sense that, with the Client Access services already using the Organization Relationships and the TargetOWAURL, to redirect Outlook and OWA clients, the capability to redirect ActiveSync clients is now also an available feature.

Of course there are some limitations, such as the device EAS version not supporting HTTP 451 redirects or cross-forest migrations.

I highly recommend that you read the official article, for all the details on this new feature.

Well done for the Microsoft Exchange Product Group! 🙂

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

1

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:

2

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*

3

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! 🙂

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.

1

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.

2

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.

3

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

4

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.

5

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! 🙂