Last Updated on July 13, 2022 by rudyooms

This blog will be about me running into some unexpected issues while I was finishing an older blog but wanted to rerun it one more time to make sure I wasn’t forgetting anything.

While enrolling the device one more time, while spending my day at MS NL headquarters together with Jeroen Burgerhout I stumbled upon some Autopilot enrollment issues (yes… again)

I will divide this blog into multiple parts

1. The Issue (as always)
2. The Solution
3. The Simple Fix because it’s always….

1. The Issue

I was finishing my blog that was mentioning 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, out of a sudden it was timing out at installing an App during the device setup

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 the Office 365 Apps as a Win32app because the build-in option could give you some issues. Please read it to get a better understanding of 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 the event 1309 with the error as 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 was expecting the Offline company portal to be failing but not the Office apps!

To be sure I also opened the Intune portal to take a look at the installation status of the Office 365 apps installation.

As shown above, it shows us that it failed the installation and is showing us the 0x000008ca error. Translating that error code to some understandable text would give you: “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 was hanging on “we’re getting things ready”…

As shown above, when running the Office Click to Run installer, it will create a nice shiny log file in the c:\windows\temp folder. When opening this log file it showed us 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 itself and copied that URL in it to determine 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… it is downloaded by using HTTP…. and NOT using HTTPS?

But 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 a little bit weird now as I was expecting it to fail.

3. The Simple Fix because it’s always….

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

As shown above, on the left is my not working VM and on the right is my own notebook, with 2 totally different IPs but luckily with 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

Suddenly it was fixed