Last Updated on November 9, 2023 by rudyooms

This blog will show you what else could break when there are Authentication Issues at Microsoft. It was definitely something I wasn’t expecting.

Please read the blog to find out what it was!… ow wait… the blog title could have ruined the surprise…

I will divide this blog into multiple parts

1. Introduction
2. It’s all in the details
3. Let’s break it!
4. Let’s check the working device and compare it!
5. Lessons Learned

1. Introduction

Last week 16-05/20-05 2022, was the week of Autopilot failures and authentication errors but while enjoying myself with these kinds of errors, something caught my eye

He is telling us that his Windows 10 Pro device isn’t upgrading to Windows 10 Enterprise when the device is enrolled with Autopilot even while the user has an M365 E3 license!

When looking closer at the issue, the first thing that probably comes to mind would be to take a look at the wonderful blog I wrote some time ago.

Escape from Windows Pro/Business

This blog would tell you how to fix it WHEN there aren’t Authentication issues at Microsoft! I guess it’s pretty obvious that this blog is going to show you a nice addition to that blog!.

2. It’s all in the Details

At that point I was wondering what could have caused that issue because normally the device would be upgraded to Enterprise instantly but why NOT when there are Authentication issues at Microsoft? Let’s take another look at the initial issue

The Online Company Portal failed to install! The Online Company portal NEEDS to have a valid connection to the Microsoft Store. You can read more about this requirement in one of my other blogs . Please read it if you didn’t because I am going to mention it a couple of times later on!

ESP: Cultural Learnings of Online Microsoft Store Apps for Make Benefit Glorious Nation of Autopilot

Could this be a coincidence that the Company Portal also failed to install or is it just a secondary problem? I decided to take another look at this MS Doc below! Maybe I missed something?

Windows 10/11 Subscription Activation – Windows Deployment | Microsoft Docs

Yes, I did!!!!! That’s for sure. This part below was something I totally missed!

“Organizations that use Azure Active Directory Conditional Access may want to exclude the Universal Store Service APIs and Web Application, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f from their all users all cloud apps MFA policy to avoid this issue.”

So did you read the blog I mentioned earlier? If not please do because I am mentioning that same AppID corresponding to exclude the Universal Store Service APIs and Web Application in Conditional Access when are having issues when requiring Online Microsoft Store apps during Autopilot.

But this time Microsoft is telling us to exclude that AppID when you are having issues with the Subscription Activation and you configure a Conditional Access to require MFA. The way I am reading it: When a subscription activation is taking place, the device reaches out to the Universal Store API to activate your license and when you are requiring MFA this could become an issue…

Let’s find out for ourselves if this is indeed the case!

3. Let’s break it!

Now we know, the Microsoft Store… uhh sorry, the Universal Store API does take care of the subscription activation, let’s put it to the test!

To be sure it was working as it should I first made sure I had a device that successfully performed an upgrade to Windows 11 Enterprise during Autopilot! I guess you need to compare a working device with a not working device when you want to know what could be relevant information and what not.

After I saw a device successfully upgrading to Windows 11 Enterprise after an Autopilot enrollment I decided to do something probably stupid!

To be stupid, I created a Conditional Access and excluded the: Windows Store for Business (wasn’t that one deprecated?)

This conditional Access rule will block that specific Store Service API! To be sure the ESP won’t be stuck I removed the Online Company Portal app as a required app during ESP.

Please Note: Don’t use this in production as it will break a lot!

After the conditional access rule was configured I wiped the device and relaunched the Autopilot enrollment. The device enrolled successfully but the device was still on the Windows 11 Pro version!

First, let’s find out if the Sign-in log you have in Azure is mentioning something!

As shown above, I am spotting some conditional access failures due to the stupid Conditional Access rule I configured. I was like, when it’s a Universal Store connection there must be something logged in the Store Event log, right?

Did you spot the time, I was getting the Conditional Access failure? In the sign-in log, it was mentioning 10:20! Let’s find out what we could find in the Store log in this time range. Here are a few errors I noticed in the Store log

It could be again a coincidence that the Store log is nagging about Licensing issues like C0EA0003 (MD_NTSTATUS_WIN_STATUS_CLIP_DEVICE_LICENSE_MISSING / CLiP device license not found.)but let’s compare that time frame with the Client-Licensing event log I mentioned in my blog I showed you earlier!

As shown above… exactly at that same time the Client-Licensing event log is showing us the 0xC03f6601, license install failed for license type:1. Again it could be a coincidence.. but I am starting to doubt it.

5. Let’s check the working device

To be sure, I wiped both the devices (working and not working) and decided to take another good look at the flow and compare it with the Sign in Azure Ad log

On the working device, I spotted some logs when the device was successfully upgraded to Windows Enterprise just at the same time the Sign-in log was telling us the sign-in to the Universal Store API was successful.

The store log is mentioning the ProductID: BF712690PLOG. I hoped I could find it in the Product names and service plan identifiers for licensing – Azure AD – Microsoft Entra | Microsoft Docs. But looking at this documentation and spending some time on google, I really can’t find anything useful about this ProductID… but again.. it can’t be a coincidence…

At the same time, I also noticed some other nice and funny event logs

As shown above, this event log tells us the “lease was successfully installed” and when looking at the Client-Licensing event log, it also shows us some other useful information

The License has been successfully installed: Microsoft.Windows.48.X19-98813. When googling on the X19-98813, it looks like it does have something to do with Windows Professional

I shut down the working device and opened my “Not Enterprise upgraded” device to determine if that X19-98813 is also mentioned when I am blocking that store API

As shown above, it gives us the 0xC0EA0003 error again but this time with the X19-98813.

5. Lessons Learned

I guess while looking at this issue and why the device failed the subscription activation I learned some stuff… Let me explain 2 of them!

5.1 The first lesson I learned:

I really didn’t know the fact that the Windows Store API Service was responsible for making sure your device is successfully upgraded to Windows Enterprise when using the subscription activation. I guess I totally missed that one in my “Escape from Windows pro blog”!

When the store is responsible for the upgrade, it would explain when there are authentication issues as last week, and even when you somehow succeeded in enrolling a device with Autopilot you could still end up with subscription activation issues!

5.2 The second lesson I learned

When you have configured a Conditional Access policy to require all devices to be compliant before they can access “All Cloud Apps” you could run into some activation issues

Because your device NEEDS to be compliant before the device can successfully be upgraded to Windows Enterprise. When you have read the blog I am constantly mentioning, you know that with the Bitlocker CSP option, your device will only be compliant after rebooting it!

This would also mean that the device could have issues upgrading to Enterprise at first login and you probably need to perform a second reboot to upgrade the device to Windows Enterprise

As mentioned below in the Microsoft Store Blog, We could exclude the Universal Store API (nowadays called the Windows Store for Business) to make sure the device gets upgraded to Enterprise

Please Note: This AppID exclusion isn’t a part of the Conditional Access Templates even while Microsoft has finally decided to add this to their docs

So I guess we need to be aware of this

Conclusion:

When things break at Microsoft, they do intend to break pretty hard! I wasn’t expecting that the subscription activation would also fail when there are Authentication issues. I guess I need to order myself a nice tile… Because the assumption is the….

Please Note: I also wrote some other blogs about licensing issues, feel free to check them if this blog didn’t help you!

Windows Licensing Series – Call4Cloud