I'm having a problem with sharepoint document check out when I publish sharepoint 2007 through ISA server. Going directly to sharepoint, document checkout works fine. However, trying to checkout on sharepoint when it is published through ISA users get an error "value does not fall within the expected range".
Explorer view also does not work when sharepoint 2007 is published through ISA.
I guessi should add a note in here, when I publish the sharepoint site through ISA using http these functions work fine. However, if i setup ISA to connect to clients using https we get errors. I have ISA setup to use standard http on the back end and https to connect to clients.
It looks like https is somehow messing this feature up though.
Any document that is edited on a library that forces checkout will fail load the document with the ISA Login page. When you try to check it out stand alone we get the "Value does not fall within the expected range." error..
We are also using HTTPS with forced redirection from HTTP
I'm currently working with microsoft pss on this issue. It sounds like, in order for this work properly, ssl has to be used all the way through. So we either publish our sites fully over http or fully over https. I should have more to share on this soon, once I can get sharepoint re-configured to use https then I should be able to use ssl the entire way through.
I had the listener to redirect HTTP to HTTPS, but I did not have the firewall rule set to use SSL Bridging. Under Bridging I only had "Redirect requests to HTTP port" checked, and not Redirect requests to SSL Port.
So in the log, while everytjing was going through HTTPS it was still passing to port 80 instead of 443. Once I checked off the redirect for SSL, my issue went away.
I got it working by using SSL all the way through. I setup AAM in sharepoint and extened the our sharepoint application using SSL. After sharepoint was setup to use SSL, I used SSL bridging to connect to the sharepoint site with ISA. Now these features work perfectly.
I too had this same problem. I sure wish I saw this posting 2 hours ago so had not thought I going crazy.
However, I do have a small problem with this configuration. I don't want to bridge HTTPS to HTTPS and use SSL all the way through. I purposely want to bridge HTTPS to HTTP. This is because I run multiple sites on the SharePoint server. This configuration works great if you assume there is only one site being published, but not so great for a hosting company. The only way to allow for multiple sites with SSL is to add an additional IP to SharePoint server for each site that requires SSL. This is a headache I want to avoid as I don't want multiple IPs on the internal servers. As an alternative, I tried bridging to alternative SSL ports, but that failed as well. It appears only 443 will work.
Now, before the security nuts yell at me for bridging HTTPS to HTTP because of the potential security flaw, I agree with you. Users deserve to expect the entire transmission to be secured. So I’m using an IPSec to secure the data from the ISA server to the SharePoint server. It’s not SSL, but it’s still encrypted and that is good enough for me to sleep at night.
This seems to be a problem with SharePoint more so than ISA in my opinion. It seems that the URLs generated by SharePoint after enabling SSL get “jacked up” and causes issues. Does anyone agree or disagree?
After I installed the ISA 2006 Supportability Update (KB939455), this fixed the URL problems cause by ISA. I also had to add an additional public URL to the SharePoint configuration in the Alternate Access Mappings (AAM) settings to include the "https".
I have not checked to see if SP1 fixes this issue as well, but since SP1 was released after the supportability update, I assume it will.
I already had ISA Server 2006 SP1 installed. I still had the problem. I will install this update on one server in my array and see if it works. I did not see anything in the list of this update that says it addresses the HTTPS / HTTP issue. However, I will try it.
925287 (http://support.microsoft.com/kb/925287/) ISA Server 2006 includes the host header together with the port number of the Web server after you publish a Web site.
That did not help either. I still have document check in issues. I also cannot see the shared workspace tools. I have a call in to MS. Maybe we can get some traction on this issue.
We ran into the same issue (Explorer view working internally but not after publishing via ISA) and have solved it.
We are using ISA Server 2006 with SP1 and MOSS 2007 with SP2. Also, we run internally using HTTP and externally using HTTPS, so ISA server bridges external traffic on HTTPS to internal traffic on HTTP.
We traced the issue to Sharepoint Server returning bad URLs voor Explorer view (namely, the internal HTTP URL instead of the external HTTPS URL) and ISA server not rewriting the HTTP URL to HTTPS.
We solved the issue by setting up the correct Alternate Access Mappings in Sharepoint (Central Administration | Operations):
We have only ONE web app, so this web app should return the https URL (so it works from outside). Therefore, the Public URL of the default zone in our case should be https://public-servername
Also, we use "Forward the original Host header" in the ISA rule, so the internal URL for this public URL should be http://public-servername. Notice that protocol in this case is http, not https, since we use http internally.
Finally, notice that when setting up Alternate Access mappings, whenever you change the public URL for a zone, the associated Internal URL also changes (so putting https in the public URL changes the internal URL to https). Also, changing the internal URL changes the associated public URL. To solve this problem, we first set the public URL to https. The Internal URL then also is https. Next, we added a second internal URL using http. This way, we simultaneously have an internal URL with http and an public URL with https: