We are currently facing a problem with SharePoint 2010 where documents cannot be checked out.

We are trying to migrate an old WSS 3.0 infrastructure to SharePoint 2010 and it seems that we have some troubles with our Extranet part.

We have an Intranet part that is already migrated. This one is on a specific network and it is only accessible by internal users over HTTP. For now, it seems that this infrastructure is alright. However, our old Extranet part we are trying to migrate is on another network, and we use HTTPS to reach it.

We are using Microsoft Forefront Threat Management Gateway to publish this Extranet SharePoint infrastructure where HTTPS and HTTP connections are enabled and HTTP traffic is redirected to HTTPS. So when the Extranet WebApplication was created in SharePoint, it was set with HTTP and the 80 port.

We can connect to the various Extranet sites, however, if we check out a document, we get the following error:

System.IO.FileNotFoundException: The Web application
at https://tenant.sharepoint.com could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to the intended application.

After some research, among many others, we found this very interesting post which is similar to our situation: https://social.technet.microsoft.com/Forums/sharepoint/en-US/228f3e49-50e4-4acf-b8b1-438e9a3ddea2/document-checkout-via-https-causes-filenotfoundexception?forum=sharepointadminprevious. Like in this post, when we try to check out a document, we can also notice that the original request comes from HTTPS and it is redirected, but the filename is not correct:

Name=Request (POST:http://tenant.sharepoint.com/_layouts/Checkin.aspx?FileName=https%3A%2F%2Fsharepoint%2Etenant%2Ecom%2Fsites%2Ffile%2Exlsx&Checkout=true&Source=https%3A%2F%2Fsharepoint%2Etenant%2Ecom%2Fsites%2F%2FForms%2FAllItems%2Easpx)

So, as it is suggested, we tried to configure AAM in multiple ways. The best we can get is, instead of the previous error, we have the following one:

System.ArgumentException: Value does not fall within the expected range.   
at Microsoft.SharePoint.SPWeb.GetWebRelativeUrlFromUrl(String strUrl, Boolean includeQueryString, Boolean canonicalizeUrl)    
at Microsoft.SharePoint.SPWeb.GetFile(String strUrl)    
at Microsoft.SharePoint.ApplicationPages.Checkin.get_File()    
at Microsoft.SharePoint.ApplicationPages.Checkin.OnPreInit(EventArgs e)    
at System.Web.UI.Page.PerformPreInit()    
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

And that is not better...

What it is also strange, is that if we open any document using the browser interface, it opens in read-only mode, regardless of the AAM configuration. Nevertheless, if we access a document using the Explorer View, we don't have any problem. The file can be edited as usual. It seems like WebDAV requests are not a problem, but when it comes to HTTPS this where things turn bad (but maybe it is a false idea).

We don't know if it is related, but it is a strange behaviour around the same thing.

We checked the WebApplication settings, database, permissions, browser emulation mode without much more success. The database is not in read-only mode, permissions are good and quotas for the WepApplication seem to be alright.

Our Intranet infrastructure, except the HTTPS, use the same settings and SharePoint features and doesn't seem to have this problem.

This post, https://stackoverflow.com/questions/1822751/wss-error-when-trying-to-check-out-pdf-files, sounds also like our problem. Unfortunately, it didn't help us neither.

To migrate our various old WebApplications, we created a corresponding one on the required SharePoint server, deployed and activated the required packages and features, export the old database and the attached it to the corresponding WebApplication.

Do we have to extend our Extranet WebApplication or set AAM in a different way? Any suggestion or help would be much appreciated.

Many thanks in advance.

Best regards,


This problem was indeed related to HTTPS and SSL. We found two solutions for this problem:

  1. If we want to use SSL offloading at the TMG server, Josh McClanahan's solution is the best (it was the standard way for us to do things like that a few years ago)
  2. If we want to avoid TMG and do things in a more direct way, the best way is to create the WebApplication with SSL, using port 443 and to add the SSL certificate on the SharePoint server (cleaner, simpler)

1 Answer 1


It sounds like you are using SSL offloading at the TMG server, I would recommend using SSL all the way through to SharePoint. Extend the Extranet webapp to https://extranet.domain.com, have the URL match what the end user is browsing to, add the SSL cert to the SharePoint server and setup the binding in IIS, and then setup TMG to forward extranet traffic to SharePoint on port 443 instead of 80.

On a side note TMG hits end of life next year so you might want to start looking at replacements.

  • Thanks for your answer and suggestion ! :) We will check that with the sysadmin.
    – Lancelot
    Commented Sep 12, 2019 at 6:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.