Sharing the experience search

Search sharing-the-experience.blogspot.com

Friday, February 10, 2012

layouts/inplview.js? access is denied

[Question]:
layouts/inplview.js? access is denied


In SharePoint 2010 when I am trying to get a item menu by right clicking on the item I am having a javascript error:
layouts/inplview.js? access is denied
How can I fix it?


[Answer]:


I have resolved this error by correcting AAM (Alternate Access Mapping) records.


 My issue was that I have configured HTTPS between user and ISA, but set HTTP between ISA and the SharePoint server. ISA: How to redirect HTTP to HTTPS, How to set SSL Certificate


Such configuration is called "off-box SSL termination." But, I have setup AAM in incorrect way.


The correct AAM for "off-box SSL termination" is to use HTTP and HTTPS urls as Internal URLS for one default HTTPS Public URL(in case public and internal hostname are equal in ISA):






P.S. In case you haven't setup SSL certificate on the web server and you want to request site locally avoiding trip to ISA, add to local host file as an example perimiter.portal2010.local with IP of the server; and then add AAM for this hostname. It will do the trick.







6 comments:

  1. Stumping me aswell. Does your solution mean I will have to have all internal traffic on https?

    ReplyDelete
  2. No, it does not. If you don't have https, but experience this behavior, take look at your AAM, here is a high chance that it's not setup correctly. In order to troubleshoot, try to access this layouts/inplview.js using different url that you have in AAM

    ReplyDelete
  3. Thanks Natalia. Surely something amiss with AAM. My config is almost the same as yours (http returned back as https using AAM. ie public URL is https). Works for most part but if I provide full path to a aspx page, it seems to ignore my AAM. i.e http://xyz.com/sites/abc/default.aspx would not redirect to https, but http://xyz.com/sites/abc would.

    My public URL was http://xyz.com, at the time of attaching the content db's. Wondering if that leaves hard coded refrences in the DB, and whether I should reattach the DB, with public URL as https.

    If that is the case, then I have a larger problem on account of hard coded refrences to http in CEWP, workflows etc which I imagine will not be returned as https. Befuddled :)

    ReplyDelete
  4. Hello, Rohit.
    Yes, the behavior is strange if http://xyz.com/sites/abc/default.aspx won't get re-directed to https.
    I don't believe that your prev http url got hardcoded while attaching.
    But I do believe that it's something in your AAM.
    Here is my suggestion:
    As I showed in the post, make sure that DEFAULT PUBLIC url is HTTPS.
    Then remove internal HTTP. Leave only https.
    Test with this url.
    Then if it works, add internal HTTP back to HTTPS, pay careful attention to ZONE and WHAT'S your PUBLIC URL.

    Good luck

    ReplyDelete
  5. Darn, it was a misconfigured load balancer. And here I was losing my trust on AAM to do its job. SharePoint and me still pals :)

    Thanks for your help Natalia, much appreciated.

    ReplyDelete
  6. Very helpful Natalia, thank you!
    I've been in a job 2 weeks where they have been having this problem for months, netscaler load balancer is handling "off-box" https.
    The procedure was:
    Edit existing Internal URL to be https - temporarily breaking internal http access.
    Add second Internal URL for https and the result is as in your screen shot,.
    One Internal URL http with Default zone Public URL https.
    One Internal URL https with Default zone Public URL https.

    ReplyDelete