443 https traffic window 2012 r2 server with IIS

do you have a network segment or a distribution point setup in the JSS for that location/traffic?

Our currently our distribution point is on our main server that houses the JSS.

Looks like Self Service is trying SMB when off the network?

Check your file distribution point settings. Make sure that it is using HTTPS. You can't really. configure an HTTPS only DP, so you tell it to use HTTP, then fill out dummy values for the File Server tab.

Also, you said you had a load balancer.

How confident are you about configuring the JSS nodes to work with LB's? Did you configure the Tomcat server settings "to work behind a load balancer?" Also, when you do this, you should probably enable remote IP valve. The proxy port /protocol is whatever the LB is set to listen on. The LB should then forward to each node on :8080. You can access the JSS nodes on http:8080 or https:8443.

In your system settings, what is the full JSS url and port? https://your.jss:443 ? Is your load balancer listening for clients on 443 or 8443?

If you have the load balancer listening to 443, then it's going to randomly assign incoming https connections to one node or the other, which means you might not get your files.

Also, the LB should be configured with "SSL persistence" so that clients are pointed to the same node for a duration, and not bounced around in the middle of a transaction.

Grabbed the wrong response error.

How confident are you about configuring the JSS nodes to work with LB's?
confident.
Did you configure the Tomcat server settings "to work behind a load balancer?"
Yes

Also, when you do this, you should probably enable remote IP valve. The proxy port /protocol is whatever the LB is set to listen on. The LB should then forward to each node on :8080. You can access the JSS nodes on http:8080 or https:8443.
Done and yes

In your system settings, what is the full JSS url and port? https://your.jss:443 ? Is your load balancer listening for clients on 443 or 8443?

https://your.jss:8443
Client check in on 8443, files are pulled from an inbound connection to a single server behind the load balancer on 443 .

If you have the load balancer listening to 443, then it's going to randomly assign incoming https connections to one node or the other, which means you might not get your files.

Not if you instruct your folks who built your load balancer to direct traffic at only one server. Also as I said I can get to the Casper share from the browser without issue.

Also, the LB should be configured with "SSL persistence" so that clients are pointed to the same node for a duration, and not bounced around in the middle of a transaction.

I will have to make sure that was completed, when we add the other instance.

https://www.jamf.com/jamf-nation/articles/309/using-iis-to-enable-http-downloads-on-a-windows-server-2008-or-2012-file-share-distribution-point

Have you looked at this nation post?

Did you generate a self signed cert from the JSS to install in IIS? Or are you using public certs?

Have you configured IIS to ignore, allow, or require SSL?

Your managed clients may be rejecting an unsafe connection.

As a stated in the beginning post.

"The cert we use is an in house generated cert created from a CSR generated in IIS and handed off to our cert creation folks."

Yes we configured it to allow SSL, and as I stated we can get to the share from a browser connection without issue so that infers that IIS is doing what it is supposed to.

@ifbell Have you fixed this issue. I'm looking for a similar fix? We just went to a two server setup behind a barracuda load balancer. We're having the exact same problem, can't route 443 traffic to our CasperShare. SMB internally works fine, HTTPS was fine before load balancer but is now broke.

Thanks,
Chuck