HTTP Downloads failing from IIS Windows

fridomac
New Contributor III

Hello!

Since November or so I see HTTP Downloads (from an HTTP-DP served by IIS on our Jamf Pro Server)
Server is Jamf Pro 10.42.1 running on Windows 2016 Server (it is the "DMZ"-Server of our clustered pair)

Jamf only logs a "Package not found" although the Packages are definitely there, and I get a "404 0 2" error in the http-Logs. 

That mostly happens when the machine is first set up (DEPNotify is started right after the Setup Assistant finishes and users see the Finder for the first time.

When the machine retries after setup ist finished (Policies are triggered through custom triggers and have retries set) then everything downloads ok.

I am really stumped, has anybody seen something similar? MIME-Types are all set, the IIS on that Server was working fine up until November, when we moved the main Server to a different Datacenter.

 

Bye, Fridolin.

1 ACCEPTED SOLUTION

AJPinto
Honored Contributor III

If the server is on prem or IaaS remote on to it and check the ISS logs. If its PaaS or SaaS you will probably need to get whoever is hosting the server to pull the logs for you. 

 

Generally speaking, I try to front load as few applications as possible during enrollment. Packages take time to transfer, it is possible things are timing out especially with stuff like Office as it is chunky. It may be best to just have your required applications drop during enrollment, and everything else drop at 1st check in or be self serviced. 

View solution in original post

4 REPLIES 4

fridomac
New Contributor III

I have to add, not all Packages are failing, but different ones on each enrollment, sometimes it is Word, sometimes swiftDialog, sometimes Teams, it seems to be random...

AJPinto
Honored Contributor III

If the server is on prem or IaaS remote on to it and check the ISS logs. If its PaaS or SaaS you will probably need to get whoever is hosting the server to pull the logs for you. 

 

Generally speaking, I try to front load as few applications as possible during enrollment. Packages take time to transfer, it is possible things are timing out especially with stuff like Office as it is chunky. It may be best to just have your required applications drop during enrollment, and everything else drop at 1st check in or be self serviced. 

fridomac
New Contributor III

Thank you for the reply.

The Server is on-prem, I checked the IIS logs, and it just looks like it cannot find the Package:

Source-IP redacted, ServerUser, 1/13/2023, 14:32:28, W3SVC1, ServerName, Server-IP redacted, 15, 345, 1413, 404, 2, GET, /path/Packages/SG Support-2.4.2.pkg/index.bom, -,
Source-IP redacted, ServerUser, 1/13/2023, 14:32:28, W3SVC1, ServerName, Server-IP redacted, 15, 329, 1413, 404, 2, GET, /path/Packages/SG Support-2.4.2.pkg, -,
Source-IP redacted, ServerUser, 1/13/2023, 14:32:28, W3SVC1, ServerName, Server-IP redacted, 15, 345, 1413, 404, 2, GET, /path/Packages/SG Support-2.4.2.pkg/index.bom, -,
Source-IP redacted, ServerUser, 1/13/2023, 14:32:28, W3SVC1, ServerName, Server-IP redacted, 15, 329, 1413, 404, 2, GET, /path/Packages/SG Support-2.4.2.pkg, -,

 When the client tries again, the download is successful most of the time, sometimes it takes a couple of tries. In Jamf Pro it just says "SG Support-2.4.2.pkg is not available on the HTTP server.".

Very strange.

Bye, Fridolin.

fridomac
New Contributor III

Ok, did some more tests, but even small packages like SwiftDialog are failing sometimes. I disables HTTP/2 to see if that makes a difference, but no change. The package download just terminates. If I do a "jamf policy" after the enrollment has finished, it goes through. 

Bye, Fridolin.