Company Portal failing during Autopilot Device Preparation (AP-DP) with 0x87D30017? It might be your region settings. This blog will focus on how specific region settings could prevent the Company Portal from being installed from the Microsoft Store.
Introduction
In most Windows Autopilot Device Preparation (AP-DP) deployments, the Company Portal app is set as an allowed application. The moment the app is configured as an allowed app, it is required to be installed during enrollment.
By assigning the Company Portal in the system context, we ensure it is installed during the device setup phase, before the user even logs in.
The goal is simple: have the Company Portal installed and ready the moment the user reaches the desktop. This flow improves user onboarding, reduces unnecessary support tickets, and provides users with a clear view of the device’s status.
The same logic applies to Autopilot V1. If we really want to improve that user onboarding experience as well, we need to configure the Company Portal to launch automatically after Autopilot completes. If it launches automatically after enrollment, the user doesn’t have to search for it. Everything is fine until the enrolling user tells the device that it is located in a region like Lebanon.
The user starts enrolling the Device.
The user powers on the device and selects Lebanon as the country or region
At that point, the home location is set to GEOID 139, and things start to quietly fall apart.
As shown below, when deploying the Company Portal in the system context and requiring it as a Microsoft Store app during AP-DP, the device hits a blocking condition. The user ends up stuck on a screen that says it cannot complete device setup.
The Company Portal App fails to install. And because it’s a blocking app, the Autopilot Device Preparation process fails completely. Let me show you why.
Company Portal Not Detected: 0x87D30017
The moment the device starts provisioning, the ESP kicks in, and everything appears to be fine… until it doesn’t. Your Autopilot (Device Preparation) enrollment will fail, and when you look at the Logs, you will notice the Detection Error -201625017 everywhere.
When you open the Intune portal to check the Company Portal App installation state on the device, we notice that we receive the 0x87D30017 – Package not found error.
So, how to continue? Well.. that’s where I come in.
The Root Cause of the errors: 201625017 and 0x87D30017
The store app issue lies in how the Microsoft Store handles app availability. Microsoft’s backend filters which apps are available based on the device’s region. That logic is enforced not only in the Store UI, but also in the backend APIs used by Winget and the Intune Management Extension.
Winget/Intune Management Extension both rely on the same DLL:
- Microsoft.DesktopAppInstaller.dll
- PackageManager.dll
Under the hood, they all query the same URL: storeedgefd.dsx.mp.microsoft.com, and those queries include region-specific metadata in the headers.
If the device is set to Lebanon, the region keyword LB is included. That’s enough to filter out the Company Portal Store app. With the Company Portal app not available, your Autopilot Enrollment will fail with the error 0x87D30017!
Change the region to Netherlands, rerun the exact same query, and the Company Portal shows up in the response. The region keyword is the only difference. Shall we zoom in on the Root Cause details and how I confirmed the story above?
Confirming the 0x87D30017 issue with Winget
We didn’t stop at the error code 0x87D30017. To confirm what was happening, we ran several tests using Winget, the Microsoft Store app, Fiddler, and verbose logging.
Using winget search “Company Portal” -source msstore-verbose-logs. We tested devices with different region settings.
When the region was set to Lebanon, the Company Portal simply wasn’t returned when performing the winget search for the company portal. No results… No package found matching input criteria.
We repeated the same search after switching the region to the Netherlands, and there it was.
Since Winget did not show any results when the location/region was set to Lebanon, I was curious what Fiddler could show me.
Digging into the “No Package Found” Error
So I configured Fiddler (check out my Patch-N-Rant session on how to set it up and to configure it). To ensure I could capture the Microsoft Store Traffic, I also added an additional registry key to disable the Certificate Pinning for the Microsoft Store/ Desktop App installer.
After everything was set up, I opened Fiddler, and when I executed the same winget search command, we could clearly see the backend request to https://storeedgefd.dsx.mp.microsoft.com/v9.0/manifestSearch.
The moment use winget to search for the Company Portal, Winget (and also the WinStore.App) will try to find the GEO location of the device.
Once winget or the store app finds the proper region, it will try to reach out to the storeedgefd.dsx.microsoft.com URL and will pass that GEO location (KeyWord/Platform) in the headers. We can spot this same behavior in the WindowsPackageManager.dll as shown below.
The only difference between the Microsoft Store and Winget was the presence of the region, which was passed via the “Keyword” or “market” field in the payload. If you open the WinGet Logs from the DiagOutputDir, you will notice the same behavior.
After noticing the KeyWord in the WinGet logs, I switched to Fiddler itself.
Tracing the Failure in Fiddler
When set to LB, the backend returned a filtered result with no Company Portal being mentioned in the Fiddler Response.
When set to NL, the full manifest, including Company Portal, was returned in the response.
We repeated the same test using the Microsoft Store app itself.
When switching the device region to Lebanon via Settings, the Store app prompted us to restart it to finish our change to the region or language.
This was a strong indicator that something region-specific was being applied internally. After reopening the Store, it became clear that the Microsoft Store was no longer showing the Company Portal app as an available app.
At the same moment we searched for the Company Portal App, we also had Fiddler up and running. We noticed that it made the exact same request to the same endpoint (storeedgefd.dsx.mp.microsoft.com) again, including the region in the headers payload.
This proves that Winget, the Store app, and IME all depend on the same backend and are affected by the same filtering logic. If the app is excluded in a region, it doesn’t matter which tool you use it won’t show up.
Validating Company Portal Availability Across Regions
After confirming that region filtering was blocking the Company Portal in Lebanon, we wanted to determine the extent of the issue.
To do that, Kevin (the one who approached me with the issue) created a script that loops through all known GEOIDs and checks if the Company Portal is available via Winget.
It quickly highlights in which countries the app can or cannot be found when using the Microsoft Store backend.
You can find the script here:
Detect-CompanyPortalAvailability.ps1 on GitHub
This approach helps identify region-specific gaps in advance, so you don’t have to wait for Autopilot to fail before discovering that the Company Portal isn’t available.
Why AP-DP Fails with 0x87D30017
I guess this is pretty simple, but if the required Microsoft Store app isn’t available, IME has nothing to install. The detection will fail and it throws 0x87D30017. The ESP waits, retries, and eventually fails. That alone is enough to break the Autopilot experience.
It gets worse. Even if the region is temporarily changed to something supported and the app installs, switching the region back to Lebanon can trigger IME to fail app revalidation. It checks for the app again using the same Store logic, and the app is once again invisible.
The result? Intune reports the app as failed, even though it’s installed and working. And if Autopilot is still waiting on ESP, that’s enough to stall provisioning.
Workarounds to avoid the 0x87D30017 error
Option 1: Use the Offline or Win32 Version
The cleanest solution is to stop relying on the Microsoft Store version of the Company Portal altogether, at least for the required Autopilot Apps, if you are based in a location that doesn’t have access to the company portal. Use the offline MSIX package or repackage it as a Win32 app and deploy it through Intune. This bypasses all the region-based filtering logic in the Store backend. For everything beyond the Company Portal, Patch My PC is the tool you’ll want in place.
Option 2: Switch to the User install Behavior?
Instead of using the system install behavior for the company portal app, we can switch back to User install behavior
By switching it to User install behavior (or removing it as a required app during enrollment), the Company Portal will be installed later on (which will fail eventually), but with it, your Autopilot enrollment itself wouldn’t fail.
Option 3: Add a Remediation to Handle Region Switching
If you still want to use the Store-based version, build a remediation script that:
- Checks the current region (get-winhomelocation)
- Tries to run winget search “Company Portal”
- If no results are returned and region is LB:
- Temporarily sets the region to NL or US
- Installs the app with Winget
- Reverts the region back after installation
This allows you to force installation during Autopilot even when the Store backend would normally block it based on region.
Microsoft Mentions It, But Lightly
Microsoft does hint at this in their documentation:
“If you assign an app to a device that is located in a region where that app is not supported, the app will not install on the device. However, if the device is moved to a region that supports the app, the app will install on the device.”
That’s about all they say. There’s no list. No matrix. No documentation is available on which apps are available where. You can only find out by testing in that region or waiting for your Autopilot flow to fail.
And that’s the real issue here. We need visibility. A public list of Store apps and their supported regions would go a long way in helping administrators avoid silent failures like this.
Final Thoughts
The 0x87D30017 error isn’t caused by Winget or IME but by region-aware filtering quietly enforced by the Microsoft Store backend. If you rely on Microsoft Store Winget apps during Autopilot, you need to test per region or avoid the Store entirely until Microsoft provides more transparency.
Company Portal might not be available through Patch My PC, but it’s a good reminder that for managing all your other apps reliably and without regional surprises, Patch My PC is the tool you want in place. Book a demo if you want to hear more!