In this blog, I’ll discuss the unexpected challenges I encountered during an Autopilot deployment, specifically the 0x000008CA error. This error surfaced while the Office apps were attempting to install, but unfortunately, they kept timing out, leading to timeouts (0x80073cfb) in the Autopilot deployment process. I’ll walk you through the troubleshooting steps I took and share insights on how to fix similar issues if you encounter them in your environment.

1. The 0x80073cfb Issue

I was finishing my blog, which mentioned the error 0x80073cfb you could receive during Autopilot when using the Offline Company portal.

I wanted to be sure I covered everything and decided to rerun the Autopilot again, but today, all of a sudden, it was timing out at installing an App during the device setu.p

Okay, normally, this could be due to using the build-in option in Intune to deploy the Office 365 Apps, but this time, it wasn’t that specific issue. Some time ago, I wrote a blog about deploying Office 365 Apps as Win32 apps because the built-in option could cause issues. Please read it to better understand what could break.

Deploy the Office 365 Apps in Intune with a Win32App (call4cloud.nl)

2. Troubleshooting

As always, when you need to troubleshoot some App installations during Autopilot, the DeviceManagement-Enterprise-Provider event log will be one of the first places to start digging. So did I! After scrolling down through all the impersonate 0x86000022 errors and some other useless information, as shown below

I stumbled upon event 1309 with the error shown below. It’s mentioning the installation of resource encountered an error and could not complete. When taking a look at the resource name that encountered an error it is mentioning the ./vendor/MSFT/Office/Installation

That’s odd? I expected the offline company portal to fail, but not the Office apps!

To be sure, I also opened the Intune portal to check the status of the Office 365 apps’ installation.

As shown above, it failed the installation and is showing the 0x000008ca error. Translating that error code to understandable text would give you the following message: “The network connection could not be found.”

I reinstalled the device and started the enrollment again, but this time without the Office 365 Apps configured as a required app, and I also removed the assignments. After the device was enrolled, I instead used the Office Click to Run setup I got from the Win32app package that I created some time ago.

After launching the Office 365 Apps setup, it hung on “we’re getting things ready”…

As shown above, running the Office Click to Run installer will create a nice, shiny log file in the c:\windows\ temp folder. Opening this log file showed that it was trying to fetch the CAB file from the Office CDN, but as shown below, it was not reachable!

I opened Microsoft Edge on the device and copied that URL into it to see if I could manually download it.

http://officecdn.microsoft.com/pr/55336b82-a18d-4dd6-b5f6-9e5095c314a6/Office/Data/v64_16.0.15028.20248.cab

As shown above, is it downloaded using HTTP and NOT using HTTPS?

However, just like with the Office 365 apps, I ended up with a nice 404 error. That’s very odd because if there were Office CDN issues I would probably have known by now. So, I opened my Edge browser on my own device and copied the same URL in it.

As shown above, my device downloaded that CAB file without any issue. Okay? Things are getting slightly weird now as I expected it to fail.

3. The root cause of the 0x000008CA ….

I decided to start a CMD and just start by pinging officecdn.microsoft.com first because it can’t be a DNS issue, right?

As shown above, my not-working VM is on the left, and my notebook is on the right. They have totally different IPs but luckily the same CNAME: e1723.dscs.akamaiedge.net. The funny thing is that both my own device and my test VM were using the same DNS servers.

To be sure it wasn’t just a CDN issue, I performed the same tests on multiple different networks and devices and they all showed IP addresses in the 2.17.172.x IP range, none of them showed me the 104.x.x.x IP range

I decided to change my host file a little bit on my VM to make sure those DNS names were resolved to the other one. After changing it and rerunning the Office 365 setup manually it worked. Okay… I guess we can be pretty sure now that it’s always DNS

But still why? As I was using the same public DNS server! I decided to switch to a different DNS server (1.1.1.1 / CloudFlare) in my test LAB its DHCP pool and reinstalled the VM and started the Autopilot setup.

As shown above, this time it worked without any issue…

Conclusion

Office CDN issues or the built-in Office 365 Apps could get you in trouble during an Autopilot enrollment but it doesn’t mean the Win32app version is ALWAYS working because there is always DNS.