Hi Everyone. I wanted to share some information on O365 licensing. I recently was working on a project where bulk licensing changes were needed, and the requirements included setting licenses in a granular fashion, to included/exclude certain services, instead of just setting the full License. As a result, I compiled some of the links, syntax, and approach I used which was the most effective method for me to understand and accomplish this task.

 Understanding

First we need to understand licensing a bit.  Anyone working in the O365 space understands licensing to a certain extent. As the planning discussions progress, organizations must determine which Licenses to purchase for their end users. Each license level (AccountSkuID) comes with a set of functionality, and license levels can be mixed among the user population based on the organizational requirements. The 2 links link below describes the various licensing levels, and provides an overview of the associated functionality with those licenses.

Plans for Business:

https://office.microsoft.com/en-us/business/compare-office-365-for-business-plans-FX102918419.aspx

Kiosk Plans:

https://office.microsoft.com/en-us/business/compare-office-365-kiosk-plans-FX103178917.aspx

That’s all great, but in my case we wanted to assign these licenses and enabled each service for the end user, as needed. We wanted Lync enabled for some users, Exchange for others, Sharepoint for others, and several combinations thereof.

So how exactly do we do that, on a scale where the tenant contains thousands of users? Opening each user account and assigning the license through the portal isn’t an option. Let’s explore the real solution.

 Application

We had thousands of users, with various license plans and services already enabled. Before we could decide what needed to be set, we wanted to first understand what is set for the existing user population. Instead of reinventing the wheel here, I used a script which works pretty well. Linked below.

Overview:

https://blogs.technet.com/b/heyscriptingguy/archive/2012/09/02/weekend-scripter-use-powershell-to-manage-office-365.aspx

Download:

https://gallery.technet.microsoft.com/scriptcenter/Export-a-Licence-b200ca2a

We ran the script, got the export, cleaned it up a bit, and then we had to do some analysis. This export however acted as the source of record for what we are setting in O365. Essentially we carved up the export into different spreadsheets, requiring one spreadsheet for each licensing configuration we wanted to assign.

Each spreadsheet will contain the UPN, License Type (AccountSkuID), and which services need to be enabled/disabled from the licenses. Again, we create a separate spreadsheets for each variation in licensing, as each licensing script will be specific to the variations we are separating out.

Once we start looking at how we are going to set licenses, and specifically at the way the cmdlet is used to configure granular license assignments, it will become clear why we break these up into separate spreadsheets. So let’s take a look at the syntax to execute these bulk assignments:

 Scripting the Solution

If we want to apply the licenses to users, and enable all services with that license assignment, its pretty straight forward. Create/Modify our spreadsheet with a list of UPNs, save it in the c:\temp directory, and run the script below.

The tenant domain name referenced is the domain name associated with the tenant (tenant_domain_name.onmicroscoft.com), not the federated or shared domain name from the on premise organization.

E1 Full License:

#Bulk E1 License Assignment with no Services disabled

$AccountSkuId = "<tenant_domain_name>:STANDARDPACK"

$UsageLocation = "US"

$LicenseOptions = New-MsolLicenseOptions -AccountSkuId $AccountSkuId

$Users = Import-Csv c:\temp\Users.csv

$Users | ForEach-Object {

Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation $UsageLocation

Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $LicenseOptions

}

E3 Full License:

#Bulk E3 License Assignment with no Services disabled

$AccountSkuId = "<tenant_domain_name>:ENTERPRISEPACK"

$UsageLocation = "US"

$LicenseOptions = New-MsolLicenseOptions -AccountSkuId $AccountSkuId

$Users = Import-Csv c:\temp\Users.csv

$Users | ForEach-Object {

Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation $UsageLocation

Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $LicenseOptions

}

Each AccountSkuID has a corresponding value needed for this portion of the script. The options from the scripts above are:

• STANDARDPACK = E1 License

• ENTERPRISEPACK = E3 License

Granular Service Enablement

Now that we understand how to assign the license, what if we want to granularly control what services within the license are enabled/disabled. The answer is in the new-msollicenseoptions cmdlet, and the DisabledPlans parameter. In the script examples you’ll see below, we specify the disabledplans value, and reference that as we loop through the foreach script. This is why we broke the spreadsheet up based on license assignment. It is structured to apply a license (accountskuid) and a set of disabled plans (disabledplans parameter), to all users in a spreadsheet that we imported. The spreadsheet only needs to contain a single column with a heading of UserPrincipalName, and the corresponding list of UserPrincipalName's in the rows below it.

To the sample scripts…

E3 with only Lync Online Enabled:

#Bulk E3 License Assignment with RMS, Office Pro Plus, Office Web Apps, SharePoint Online, and Exchange Online disabled

$AccountSkuId = "<tenant_domain_name>:ENTERPRISEPACK"

$UsageLocation = "US"

$LicenseOptions = New-MsolLicenseOptions -AccountSkuId $AccountSkuId -DisabledPlans RMS_S_ENTERPRISE, OFFICESUBSCRIPTION, SHAREPOINTWAC, SHAREPOINTENTERPRISE, EXCHANGE_S_ENTERPRISE

$Users = Import-Csv c:\temp\Users.csv

$Users | ForEach-Object {

Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation $UsageLocation

Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $LicenseOptions

}

E3 with RMS and Lync Disabled:

#Bulk E3 License Assignment with RMS and Lync Online disabled

 $AccountSkuId = "<tenant_domain_name>:ENTERPRISEPACK"

$UsageLocation = "US"

$LicenseOptions = New-MsolLicenseOptions -AccountSkuId $AccountSkuId -DisabledPlans RMS_S_ENTERPRISE, MCOSTANDARD

$Users = Import-Csv c:\temp\Users.csv

$Users | ForEach-Object {

Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation $UsageLocation

Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $LicenseOptions

}

E3 with RMS and Office Pro Plus Disabled:

#Bulk E3 License Assignment with RMS and Office Pro Plus disabled

$AccountSkuId = "<tenant_domain_name>:ENTERPRISEPACK"

$UsageLocation = "US"

$LicenseOptions = New-MsolLicenseOptions -AccountSkuId $AccountSkuId -DisabledPlans RMS_S_ENTERPRISE, OFFICESUBSCRIPTION

$Users = Import-Csv c:\temp\Users.csv

$Users | ForEach-Object {

Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation $UsageLocation

Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $LicenseOptions

}

E1 with Exchange Online and Lync Online Disabled:

#Bulk E1 License Assignment with ExO and SpO Disabled

$AccountSkuId = "<tenant_domain_name>:STANDARDPACK"

$UsageLocation = "US"

$LicenseOptions = New-MsolLicenseOptions -AccountSkuId $AccountSkuId -DisabledPlans:SHAREPOINTSTANDARD,EXCHANGE_S_STANDARD

$Users = Import-Csv c:\temp\Users.csv

$Users | ForEach-Object {

Set-MsolUser -UserPrincipalName $_.UserPrincipalName -UsageLocation $UsageLocation

Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -LicenseOptions $LicenseOptions

}

The only difference between the various scripts above are the AccountSkuID’s (license type), and the License Options (disabledplans parameter). Everything else remains the same. That makes these scripts a pretty good plug and play option, especially if you’re supporting an organizations that doesn’t want to standardize licensing, and requires more granular control over service enablement.

Key Options included in the Above Scripts

• DisabledPlans:

• OFFICESUBSCRIPTION = Office 2010

• MCOSTANDARD = Lync Online

• SHAREPOINTWAC = SharePoint Online

• SHAREPOINTENTERPRISE = SharePoint Online

• EXCHANGE_S_ENTERPRISE = Exchange Online (E3)

• EXCHANGE_S_STANDARD = Exchange Online (E1)

If you need to go beyond what I’ve explained in this article, I would strongly recommend reading through the link listed below. It covers a variety of options and syntax to accomplish various licensing operations.

https://social.technet.microsoft.com/wiki/contents/articles/11349.office-365-license-users-for-office-365-workloads.aspx

Thanks! Hope this helps…

I came across a strange issue recently, and wanted to throw it out there in case anyone runs by this in O365 land.

Background

An organization was running in a Hybrid Coexistence with O365 Wave 15. An Exchange 2007 user was migrated to the cloud. Later, the mailbox was moved back on-prem for some reason. Unfortunately, I don’t have the details to provide around the mailbox moves.  Anyway, the user then reported that O365 users were unable to email the newly migrated on premise Exchange 2007 mailbox. External users were able to send mail to this mailbox without issue.

The NDR

Diagnostic information for administrators:

Generating server: XXXXXXXXXX.xxxxxxxxx.prod.outlook.com

xxxxxx@xxxxxxx.xxxx.onmicrosoft.com

XXXXXXXXXX.mail.protection.outlook.com

Remote Server returned '554 5.4.6 Hop count exceeded - possible mail loop'

Initial Thoughts and Troubleshooting

If you search for this NDR on the internet, you’ll come across several articles which point in the direction of duplicate domain configurations, SPF records, accepted domains, connector configuration etc. In our case these did not seem to apply after a quick review. It was apparent these potential causes did not apply to our case, as this was the only person impacted by this issue post migration back the on premise environment. So now what…

Let’s look at the NDR a little closer. The generating server is in O365 so no need to check anything on premise just yet. It appears that the email address being sent to, is resolving to an address with @domain.onmicrosoft.com, when it should be sending to and address of @domain.com. Once that was identified, I review the user account and mail contact in O365 to see if there is any correlation to this unexpected name resolution. Sure enough, the mail contact was configured with an external email address of @domain.onmicrsoft.com. There’s our problem

Issue identified, time to wrap it up? Not just yet…

With the issue potentially identified, all I need to do is update the mail user object in O365. Easier said than done in a Hybrid environment running DirSync. I first attempted the cmdlet below through a Remote PowerShell session:

Set-MailUser <user> -ExternalEmailAddress <primary smtp address>

And got the dreaded red output below…

The operation on mailbox "xxxxxxx" failed because it's out of the current user's write scope. The action 'Set-MailUser', 'ExternalEmailAddress', can't be performed on the object ‘xxxxx' because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.

Ok, no problem here. I have to make the change on-prem. Let’s go look at the on premise environment, update the attribute there, run Dirsync, and allow it to sync across. A quick couple of PowerShell commands and AD checks later, still don’t know where this is coming from….everything looks good.

• Get-Recipient <recipient> | fl PrimarySmtpAddress

PrimarySmtpAddress: xxxx.xxxx@domain.com

• Get-Mailbox <mailbox> | fl PrimarySmtpAddress, WindowsEmailAddress,

PrimarySmtpAddress: xxxx.xxxx@domain.com

WindowsEmailAddress: xxxx.xxxx@domain.com

• I reviewed the properties from ADSIEdit, and verified the TargetAddress is blank (which is what we would expect). This is the actual attribute which syncs to O365 and populates the ExternalEmailAddress on the mail user object.

So now what?

Finally Resolved

I ran through the steps below hoping for the best, and email started flowing again…

1. Updated the on premise targetaddress attribute through ADSIEdit
• Should be in the “SMTP:xxxx@domain.com” format (no quotes)
2. Ran DirSync
3. Verified the ExternalEmailAddress attribute was updated on the O365 mail user object
4. Sent a test message
5. Received another NDR for ‘Hop count exceeded - possible mail loop’ (arrgggghhhhh!!!)
6. Noticed this time the NDR’s originating server was on premise this time
7. Removed the on premise targetaddress
8. Ran DirSync
9. Ensured it wasn’t removed from the mail user object
10. Verified the message was successfully delivered

Root cause remains unknown, but it’s assumed to be that the mailbox move back to on premise Exchange 2007 didn’t properly update the externalemailaddress mail user attribute on the O365 mail user object. I don’t think this is a common issue out there in O365 land, but I didn’t see anything written about it in my initial search online, so thought it would be worth sharing. Thanks,

Exchange, what a great system. Until recently I though I had it all figured out. A good understanding of Mail Routing and Transport, a working knowledge of Client Access workloads and their unique configurations, and expertise with high availability configurations that will keep organizations in the 5 9's for years to come. Well here comes Office 365, throwing the newest wrench in my plans to dominate the world of Exchange. I intend to focus this blog on various topics relating to Exchange on-premise and O365 so don't be turned off if you only manage on-prem Exchange. You guys and gals need to know this stuff too. Hybrid coexistence, O365 Deployment, and working with Exchange Online (administration and troubleshooting) will be my initial focus. But I promise there will be some on-prem Exchange injected as we move through various topics, as it is all connected in this intricate web of cross-org collaboration and configuration.

A little quick bit about myself. I've been working with Exchange for about 8 years now. I started with Exchange 2000, so for all those experts out there that love to say they started with 5.5 or earlier, you have one up that can never be overcome...although everyone knows that experience is relevant  these days. Just joking for anyone that just took offense. Before I got into Exchange, I was in the US Army (active and reserve). Its a big part of who I am today. For any vets out there in this space, I'm sure you can agree that this is a great field to be apart of. I'll take datacenter switchovers to filling sandbags, all day long! Well that's enough about me for now...

It's great to meet all of you. I welcome any feedback you have. I look forward to helping out the world wide community. Now lets get started...

Thanks,

Bill Sluss