Could not activate Windows 10 upgrade from Pro to Enterprise using Office 365 E3 license

You definitely want to use a for-each loop to enumerate each user and apply the license. The loop needs to call up the .UserPrincipalName from each object returned in your Get-ADUser query, as Office365 needs to work with that value when setting licenses:

Get-ADUser | %{ Set-MSOLUserLicense -UserPrincipalName $_.UserPrincipalName }

I have created my own answer here to explain a common case that I think you're describing in your question: You don't want to blanket apply the same license options to everyone.

A TechNet Blog on this matter is immensely helpful. You may not want to give your Finance team access to SharePoint Online/OneDrive for Business for data leakage reasons, or you may have a call center who you don't want to enable for Lync/Skype for Business.

To get information on your tenant, start at the top:

Get-MSOLAccountSku

This will return the license packs you have in your tenant. Some common SKUs are ENTERPRISEPACK and DESKLESSPACK. These will be listed by yourorg:LICENSEPACK under AccountSkuId.

It is important to note that each of these License packs can have features disabled from them when you apply via PowerShell (similarly, you can choose to check/uncheck option boxes in the Admin Center).

To create this subset of license options, create a new variable and leverage the New-MSOLLicenseOptions cmdlet: $LicOpt = New-MsolLicenseOptions -AccountSkuId "yourorg:ENTERPRISEPACK" -DisabledPlans OFFICESUBSCRIPTION,MCOSTANDARD,SHAREPOINTWAC,SHAREPOINTENTERPRISE,RMS_S_ENTERPRISE

(The above options would correspond to the screenshot above, I'm sure you could guess that I totally pulled it from a provisioning script.)

Finally, we can tie this back to your Set-MsolUserLicense in your ForEach loop:

$LicOpt = New-MsolLicenseOptions -AccountSkuId "yourorg:ENTERPRISEPACK" -DisabledPlans OFFICESUBSCRIPTION,MCOSTANDARD,SHAREPOINTWAC,SHAREPOINTENTERPRISE,RMS_S_ENTERPRISE

Get-ADUser | %{ Set-MsolUserLicense -UserPrincipalName $_.UserPrincipalName -AddLicenses "yourorg:ENTERPRISEPACK" -LicenseOptions $LicOpt }

As always, your tenant may vary. I hope I've given enough info for you to discover the options available and apply appropriately!

I understand your frustration with this. I just spent about 20 hours troubleshooting problems with automatic AAD joining. I am running the latest version of AD Connect, and am running an ADFS farm on Server 2016. I did NOT let AD Connect configure my ADFS servers.

I had the exact same error. The issue was a missing ImmutableID claim. This link proved to be the best resource for setting up azure AD join: https://docs.microsoft.com/en-gb/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup

There is a script listed there to automatically add the necessary claim rules. Now that i practically understand this whole process inside and out, I can say that the script actually does work and adds the correct claims rules.

However, what is misleading is how to configure the couple of variables in the script. So, I thought I would clarify based on my learning, hopefully it will save somebody some time.

• $MultipleVerifiedDomainNames: The description and name is both WRONG and MISLEADING. Set this to $TRUE only if you have MULTIPLE FEDERATED DOMAINS in your Office 365 tenant.
• $immutableIDAlreadyIssuedforUsers: If the Immutable ID (Source Anchor) for your AD Connect synchronization does NOT use objectGUID then set this to $TRUE.
• $oneOfVerifiedDomainNames: If you set $MultipleVerifiedDomainNames to $true, then set this to the Office 365 verified domain name that you want your devices to register to.

Do not change any other components of the script, and make sure you only run it once. If you need to run it again, you need to manually remove the added claims issuance rules from the RP trust or they will be duplicated.

Another very helpful thing to know when it comes to troubleshooting on Windows 10, use DSREGCMD. It has to run as SYSTEM so you'll need something like PSEXEC.

psexec -i -s cmd.exe

dsregcmd /debug

This will force an immediate registration to Azure, and report detailed information about the failure. During my testing, Windows 7 worked fine, but Windows 10 would not AD join. If the ImmutableID is the problem you'll see the error is: AADSTS90019: No tenant-identifying information found in either the request or implied by any provided credentials.

If, you included a verified domain when you shouldn't have or it's wrong you'll see: AADSTS50107: Requested federation realm object your specified domain does not exist.